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1. INTRODUCTION | 

1.1 PURPOSli AND SCOPti 

This document describes the detailed design characteristics 

of the LACIE Phase Il/Ill Status and Tracking System built for i 

the PDP 11/45 and as modified for the CAMS Procedure 1. This i 

System provides mechanisms to support the management of LAC Hi j 

imagery processing and associated evaluation material. For | 

each package of such material, tlie system maintains a record ; 

containing the history and the present status and location of 
the package as tliat package follows its track from one LAC II; 
processing station to another. The System provides means for 
generating reports on status information and on statistical 
data about the flow of material through the LACIIi stations. 

This ASATS design is based upon achieving maximum use of the 

Regional Information Management System (RIMS) to perform ASATS | 

functions. The functional design is described in terms of ] 

(.1) data base design, C2) new RIMS software built to simplify 1 

implementation of ASATS, (.5) software designed for ASATS which j 

runs independantly of RIMS, and (4) a method for constructing | 

standard ASATS reports. j 

i 

j 

1.2 BACKGROUND ^ 

■ ] 

A version of the ASATS was originally operated on COMSIlARL's ^ 

computer system. It was developed using the COMPOS IT' 77 data 
management system. In order to reduce the cost of operating 
ASATS, it has now been implemented on the PDP 11/45. 

In order that the transition from one computer system to another , 

cause minimal impart, the standard update procedures (.including 
update card formats) and standard reports were made as nearly 

as possible identical to the old ASATS system. Because a j 

i 

I 

I 



different data management system was used for the PDP 11/45 
than for the COMSHARH version, the ad hoc query and update 
processes are different. But tiie PUP 11/4 5 version provides 
similar capabilities for ad hoc query and update. Implemental ion 
of the PUP 11/45 version is bused upon the same requirement 
document (l,EC-8()75) that was previously used for implementing 
the COMSIIARK version of AHATS, 

The original version of the PUI’ 11/45 I.ACIP I’hase III ASATS was 
comi)letcd in Marcli 1977, Since then, additional requirements 
for status and tracking of computer products for tlie CAMS Pro- 
cedure 1 have been received and implemented. These additional 
data and programming requirements were dolincnited in the "Uetailed 
Ucsign Specification for the Automatic Status and Tracking System 
Modifications for LACIE Procedure 1" (TIRP 77-0020), LHC- 10529, 
JSC- 12885. 

1.3 SYSTEM UHSCRIPTION 

ASATS operates on the PUP 11/45 using the Regional Information 
Management System (RIMS), It also uses the RSX-llU Version 6.01 
operating system. ASATS System hardware requirements include: 

• PUP 11/45 with a minimum of 64 K of storage (32.K for RSX 
and 32K for RIMS and ASATS) 

9 Uisk storage (size requirement depends upon the number of 
data base records) 

• TTY compatible terminal for interactive work 

• Card reader for standard uj)date and rejun'ts 

• Printer 

• Card puncli (requirement is satisfied by off-line capability) 

• Two magnetic tape units 



ASMS software requirements include: 

• RSX“11D version 6.01 operating system 

• FORTRAN IV-Plus (F4P) compiler for software maintenance 

• Regional Information Management System (RIMS) 

The ASATS software is composed of (1) special processors 
built for ASATS to facilitate the auditing of ASATS data base 
updates, (2) RIMS commands augmented to support specific ASATS 
requirements and (3) command files (sequences of RIMS command si 
which generate specified reports, (4) data base definitions 
describing the ASATS data base to RIMS, (5) format descriptions 
describing input files and report formats, and (61 command 
files which control RSX 1 1 b system utilities. 


2. APPLICABLH DOCUMHNTS 


The following documents are applicable: 

• Large Area Crop Inventory Experiment CbACIE) Phase III 
Automatic Status and Tracking System Sper i ficat ions , Revision 
A, dated March 1977 tdocument LHC-8075, JSC- 11401) 

• RIMS Design Document, February 1970 (LHC-9504) 

• RIMS Maintenance Document, October 1970 (LHC-9506) 

• RIMS User Document, dated April 1977 (LHc;-9301, Rev. A) 

• TIRE No. 76-0085 

• ASATS Functional Design Document, November 1976 (LHC-9861, 
JSC-11835) 

• Operator's Guido for ASATS, March 1977 (LHC- 10401, JSC-12729) 

• ASATS Users' Guide, March 1977 (LHC- 10148, JSC-12535, Rev. A) 

• Detailed Design Specification for the Automatic Status and 
Tracking System Modifications for LACIH Procedure 1 (LHC- 10529) 



3, INTIiGIUTHl) TOP-LHVIil. UHSIGN 


3.1 GHNHRAL 

An overall picture of tlie PDP 11/45 Status and Tracking System 
is shown in Figure 3-1, The arrows in the diagram indicate 
flow of information. 

Figures 3-2 through 3-6 show tlie System in more detail and 
illustrate the data paths which satisfy the major requirements 
specified for the System as described In the following sections, 
These figures break the system into units by logical function. 
Section 4 will describe the way that separate parts of these 
logical systems are actually sequenced. For example, the data 
base save operation shown in Figure 3-5 will occur every night 
at the end of an update report cycle; the data base recovery 
shown in Figure 3-5 is a stand-alone operation that will never 
occur unless the data base is damaged. 

3.1.1 STANDARD UPDATE PROCESSING 

The processing paths of the standard batch mode daily update 
and report cycle are shown in Figure 3-2. Information flow 
through these paths is controlled by command files and a batch 
control-card file. 

The Preprocessor is a set of operations specially designed for 
the ASATS update card formats. It produces some of the required 
audit listings of the input cards and rearranges the cards for 
the proper sequence of processing by RIMS. RIMS makes the 
required updates to the data base and produces a file of informa- 
tion concerning all attempted updates. A Postprocessor uses 
that information to produce the rest of the required reports 
on attempted updates and to punch the cards and print the labels 
that are required by certain updates. 



Figure 3-1.— Automatic Status and Tracking System — overall view. 
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Figure 3- 5 Autoinati c Status and Tracking System -- checkpoint 
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3.1.2 STANDARD RliPORT GliNBRATlON 


Batch mode production of standard System rei)orts is illustrated 
in figure 3-3. for each of tiie standard reports there ia 
a ''canned" stream of RIMS commands to collect the information 
required for the rejiort and put it into propei' order. Selection 
of different reports as desireil is mauo by different cards in 
the hatch input control of RIMS. 

3.1.3 Al) HOC QUIiRY AND IlPDATH 

The generalized data management cai)ability of RIMS can be used 
for several different purposes, as shown in figure 3-4. Demand 
production of one-of-a-kind reports can be done through an 
interactive terminal or in batch mode controlled by cards. In 
either batch or interactive mode, RIMS can read a command stream 
or data file brought in from tape or produced by other processes. 
Information extracted by RIMS from the data base can be printed 
as a report or displayed at the interactive terminal or it can 
be used as input for other programs which miglit perform special 
analysis beyond the capabilities of RIMS itself. Some of the 
data flow jKiths shown in Figure 3-4 may be restricted for some 
users, as will be described in section 3. 1.4. 2. 

3.1.4 DATA BASF INTFGRITY 

3 . 1 . 4 . 1 Checkpoint - Restart D a ta Base Recovery 

In spite of all economically feasible controls over hardware, 
software and procedures, the data base is vulnerable to damage 
or total destruction from such causes as computer system mal- 
function, flaws in pliysical storage media, or accidental running 
of improper updates. Figure 3-S illustrates procedures wliich 
minimize the time and effort recpiired to put the data base back 
into its proper current status after being damaged. 


As shown, the data base is dumped to magnetic tape periodically 
(once per day, after making all of the day's updates is 
suggested; the time interval can be adjusted after gaining some 
experience with failure frequency for this system). These 
"checkpoint" dumps on tape are stored off-line, while the active 
data base is altered by batch and interactive updates on following 
days. If the active data base is damaged or lost, a checkpoint 
dumped tape (the most recent one dumped before the failure) is 
read back to on-line storage, wliich restores a previous day's 
active data base. That restored data base must then be modified 
by any batch-mode card updates and any intciactivc updates whicii 
have been made since the time the checkpoint dump was taken. 

Making those updates will bring the active data base to the 
condition it should have had if no failure had occurred. 

3 . 1 . 4 . 2 Access Control 

Accidental or malicious damage to the data base is minimized 
by controls which all&w data base modifications to be made only 
by authorized personnel. Some users may produce reports without 
having permission to alter the data base. for these users, 
controls built into the RIMS software restrict data flow to the 
paths shown in Figure 3-6. As shown, the permanent files of 
the active data base can be read by a restricted user, but not 
written. Writing of any temporary files required to collect 
information for report production is allowed. A password system 
is used to identify users with unrestricted read-write access 
to the entire data base. 

3 . 2 DATA BASE DESIGN 

The data base for ASATS contains two primary tyjies of data records. 
Each DAPTS record contains information about a segment that is 
pertinent to all acquisitions for that segment. The fields of 
the DAPTS records are described in Table 3-1. Each FLOCON 
record contains information about one particular acquisition 


TABLIi 3-l.^)ArTS RBCORD FORMAT 


Field 

Name 

Description 

Length 

(Char) 

— 

Start 

(Char) 

End 

(Char) 

Key 

Source 

Card 

SKG 

Segment number • 

4 

9 

12 


A 

LFl 

LAC IE phase indicator 

1 

13 

13 


A 

COUNTR 

Country designator 

0 

14 

19 

X 

A 

IdiG 

Region 

2 

22 

23 


•k 

ZONE 

Zone 

4 

24 

27 


A 

STR 

Stratum 

4 

28 

31 


A 

GD 

Global designator 

1 

32 

32 


A 

wv 

Wheat variety 

1 

33 

33 

X 

U 

PC 

Priority code 

2 

34 

35 

X 

A 

lY 

Segment tyije 

1 

36 

36 


1 

BIOWIO 

Biowindow 1 open (start date) 

4 

37 

40 


3 

BIOWIC 

Biowindow 1 close (end date) 

4 

41 

44 



BIOW20 

Biowindow 2 open 

4 

45 

48 


3 

BIOW2C 

Biowindow 2 close 

4 

49 

52 


3 

BIOW30 

Biowindow 3 open 

4 

53 

56 


3 

BIOW3C 

Biowindow 3 close 

4 

57 

60 


3 

BIOW40 

Biowindow 4 open 

4 

61 

64 


3 

BIOW4C 

Riowindow 4 close 

4 

65 

68 


3 

TOPO 

Date topo map received 

4 

69 

72 


4 

CROP 

Date crop calendar received 

4 

73 

76 


5 

ANCIL 

llite ancillary data received 

4 

! ! 

80 


6 

SSC 

Segment status character 

1 

81 

81 

X 

4,5,6 

PROTYP 

Process type 

1 

82 

82 

X 

A 

CDTAPE 

CCIT d, DTRM Tape Number 

6 

83 

88 



TCARD 

"T" card transaction date 

4 

89 

92 


r 

LUP 

Date of last change to this 

4 

93 

96 


(last 


record 

. . 





update) 



and the processing of acquisition material packages by the 
LACIE work stations. The FLOCON records are described in 
Table 3-2. RIMS uses the data base to store information about 
the data base; i.e., format records (as described in RIMS 
documentation) for data records and for input and output records. 


L 


TABLE 3-2.- FLCXX)N RECjORD FOIW 


Field 

Name 

Description 

Length 

(diar) 

Start 

(Char) 

End 

(Char) 

Key 

Source 

Card 

SEG 

Segment number 

4 

n 

12 


B 

LPI 

LACIE phase indicator 

1 


13 


B 

DATACQ 

Acquisition date 

4 

14 

17 


B 

BW 

Biowindow 

1 

18 

18 

X 

B 

FF 

Film flag 

1 

19 

19 


B 

TAPE 

GSFC tape number 

6 

20 

25 


B 

GSFC 

GS1€ processing date 

4 

26 

29 


B 

CANI 

Cf(l update date 

4 

30 

33 


B 

LPDLCO 

Date film products received 
from LPDL 

4 

34 

37 


Cl 

AICOMP 

Date segment ready for 
CAMS pickup 

4 

38 

41 


H 

PACKRIi 

Date packet received by CAMS 

4 

42 

45 


I 

RUNSUB 

Date FDB/batch data processing 
request submitted 

4 

46 

49 


J 

RUNCT 

Run count 

1 

50 

50 


(J) 

PRODRE 

Date batch products received 
by CAMS 

4 

51 

54 


K 

REWORK 

Date rework begun 

4 

55 

58 


M 

RWKCT 

Rework count 

1 

59 

59 


(M) 

TOGAS 

Date to CAS 

4 

60 

63 


X 

CAMSBP 

CAMS biophase 

3 

64 

66 


X 

CATG 

CAMS evaluation category 

2 

67 

68 

X 

X 

CURSl 

Current film status 

1 

69 

69 

X 

(last) 

CURS2 

Current product status 

1 

70 

70 

X 

(last) 

UTAPED 

Date for unload tape 

4 

71 

74 


N 

UTAPEN 

Unload tape nunber 

6 

71 

76 


N 

UNLOAD 

Unload transaction date 

4 

77 

80 


N 

LSD 

Date of last change to this 
record 

4 

81 

99 

X 

(last 

update) 











3.3 RIMS MODIFICATIONS 


This section identifies modifications and additions to RIMS which 

have been implemented to support ASATS, These changes are 

catagorized as follows; 

a. Special Update Processor - This processor was defined because 
of the requirement to implement ASATS on the PDF 11/45 

with no changes of input from the format for ASATS on tXWHARH 
using Composit *77. The processor handles all standard 
ASATS input cards. 

b. Relational Retrieval to liiiminate Redundant Data - The 
data base for ASATS has a hierarchical relationship between 
DAPTS records and FLOCON records. RIMS commands have been 
implemented to create a set of related FLOCON records for 
given DAPTS records, and to create a set of related DAPTS 
records for given FLOCON records. Also, a command for 
displaying records containing data from both a FLOCON record 
and the related DAPTS record has been provided. 

c. Access Control - A command has been provided which specifies 
which RIMS commands are allowed for each of the access 
control words assigned to different users. Also, the 
system includes a modification that requires a user to 
identify himself with an access control word at the beginning 
of a session. 

d. Computation on Data Base Content - A new comn.and allows the 
user to sum fields, field differences, compute a mean, and 
compute a standard deviation for date fields in a set of 
records. 

e. Header Control for Reports - Commands have been provided to 
allow the user to specify report iieaders and to provide 
textual description for the number of entries in a set. 



3.3.1 ASATS STANDARD DATA BASH Ul’DATl-S 


Thit; sect ion describes the ASATS data base update t>rs)cessui- , 

Jt also includes a description of an update command built 
specifically for ASATS and describes the use of input formats 
to specify processing for individual record types. 

3 . 3 . 1 . 1 Special Update Process or 

The Special Update Processor is a stand-alone program. It 
processes all standard ASATS updates. It accepts the following 
commands : 

• Bli ' Begin 

• RP - Re assign P i 1 e 

• UP ' Special ASATS update command 

• P.N “ lind 

• Rli -• Roads processing description foi- ASATS cards 

The construction of this I’rocessor uses all standard RIMS 
commands except the main program and subroutine update i^wluch 
processes the UP command). The construction of this processor 
as a task separate from RIMS allows better core utilization, 
hence better system performance. Before executing any UP 
command, an RH command must be executed to read tlie process 
description cards which describe the |irocessing for eaclt status 
and tracking card type, 

3 . 3 . 1 . 2 Si)e cial Update Comma nd 

Purpose; Updates data base from a set of input cards. Specific 
update operations are a function of card type ^specified in the 
second character of each card), data base format, and the input 
format. The input format and the data base to be used are a 
function of the card type and l.ACIli phase. 


Input i 


• Commands; Processing is begun by a DP command 

• Status and tracking input cards: Any of the current 21 

types of ASMS update cards (except Q card) arc processes 
sequentially until an HOP. 

• KOF: Processing of an input file is ended by an end -of - 

file or a blank record on the input file 

Output: Besides updating the ASATS data base, the following 

information is recorded sequentially on a file: 

• Rejected input cards 

• Cards for which the required DAPTS record does not 
exist (for *, 2, 3, -1, 5, b, B, N aiul T cards) 

• Cards for which the reiiuired FLOCON record does 
not exist 

t Cards for which the FLOCON record has not reached 
reciuired state I'or particular tyi)c of update 

• Accepted input cards which created jiew DAPTS records 

• Punched card images 

Processing: Tlie required processing is a function of card 

type. Card types are categorized as follows: 

• Category 1 - card types *, 2, 3 (in sets) 

• Category 2 - card types *, 2, 4, 5 and 6 

• Category 3 - card type 3 

o Category 4 - card type B 

• Category 5 - other card types 

• Category 6 - card types N ami T 


There is a genoralisod iTmction for adding now records and up- 
dating existing records. This function, which is driven by 
input formats, data base formats, and card type, adds or modifies 
the specified record. The general steps of processing input 
cards are ; 

• Read input card 

• Generate record ID 

• Generate external (input) format ID from table 

• Retrieve record 

• Retrieve f o rm a t s 

• hitficr add or update the recoi’d 

• Output card image reflecting, success or error 

figure 3-7 depicts the flow of this process and variations 
dependent upon category of card type. 

Table 3-3 indicates the data used for generating a record 
depending on input category. The input format is a function 
of the card type. Table 3-4 indicates the action to he 
taken upon a record retrieval failure. 

The input processing, for all fieltls of eacii card type is as 
defined in the ASATS requirements document except for Segment 
Status (diaracter in DARTS records and Act|uisition Status character 
in f’LOCON records. The information from Table 3-3 is used to 
sot the segment status character. The Acquisition Status 
Character is set to the card type. These fields arc used for 
generating the current station and status. Their use is 
described in paragraph 3.0 

The type of operation, an add or a modify, to be performed is 
a function of record type and whether or not a record already 




exists. The input format for the card type identifies the 
fields it updates and the field's data type. Table 3-5 describe 
the processing for field types on input. 
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Figure 3-7.— Special Update Processor Flow. 
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TABU; 3-5. -USE Of-' DATA TYPES ON INPUT 


Process Ing 

Alpha - update associated data base field as 
alpha 

Integer - update assoc hited data base field as 
integer (standard RIMS data type, but not used 
for AHATS) 

Set data base field value from status table 
according to card type and existing value 

Alpha but don't update data base when input 
is blank 

Record 1.1). field (no action) 

Increment data base field value by 1 on input 
(Integer field) 

Reject input if associated data base field is 
bi ank 

Set data l>ase value as a function of Iviowindow 
t a 1) 1 e a nd a c ci u i s i t i o n d a t e 


If an error condition occurs when processing an input card, an 
error file unit number is put in column 2 when the image is 
written to the message file. The input card images for new 
DAPTS records are also written to the message file; in them, 
column 2 is the unit number for the new DAPTS record report file 

Additional processing required by category 3 is the selection of 
FLCKXIN records of the same segment and the updating of their 
biowindow fields. 

3 . 3 . 1 . 3 Use of Input Formats 

An input format is required to describe certain in'ocessing asso- 
ciated with each record typo. Tliis dcscrijition includes: 

• Identification of each field affecting the update process 

• Type identification of each field, wliicli defines how the 
field affects the update process (see section 3. 3. 1.1). 

• Starting location and lengtii of eucli field of information on 
the data card (it should be noted that some fields affect the 
processing, but do not exist on the data card, therefore do 
not have a starting location and length) . 

The field names used must correspond to tiie field names used in 
the data base definition (see Tal)i.cs 3-1 and 3-2). Field loca- 
tion and field use on input cards are described in the A.SATS 
requirements documents and in the ASATS User's Guide (Rev. A). 

Implementation using input format definitions allows for simple 
accommodation of most types of changes in input requirements. 

The addition of a new card type vvrould require a modification of 
tables within the special update command processor. The.B and 3 
type input cards do have codes wJiich are unique to them. 


3.3.2 SPKCIAL COMMANDS FOR ANNOTATING REPORTS 


A new command (header) allows the user to include text which is 
not a part of the data base and to include printer carriage con- 
trols. Another now command is included which allows the user to 
print a set count with text whicli he specifies. 

3 . 3 , 2 . 1 Header Command 

Purpose: To insert header or comment on report. 

Input: HDN, Text 

where: HD is the command mnenomic 

N is the number of input lines (1 or 2) 

Text is the header contents 

Output: N lines of text 

Processing: Text is transferred from the command file to the 

report file with the first character after the comma being used 
for carriage control. Standard FORTRAN conventions are used for 
carriage control. 


3. 3. 2. 2 Count Command 

Purpose: To print the number of entries in a set along with text 

comment. 


Input: SCSN,LOC, Text 


where: SC is the command 

SN is the set number for the count which is to be 
printed 

LOG is the column count where the set count is to 
be printed 

Text is the text data to be printed 


Processing: Text is transferred from the command 

report file and the number of entries is printed 
first text character is used for carriage control 


file to the 
with it. The 




3.3.3 SOFTWARE TO ELIMINATE REDUNDANT STORAGE 

The following new RIMS commands were designed in order that cer- 
tain data docs not have to be stored redundantly in both DAPTS 
and FLOCON records. The DAPTS and FLOCON records of the ASATS 
data base have a hierarchical relationship. The DAPTS record 
(the parent record) contains information common to possible 
several FLOCON records. 

3. 3. 3.1 Generate Parent Set 

Purpose*. To generate a set of parent records (DAPTS records, for 
ASATS) from a child set (FLOCON records, for ASATS) 

Input: GPSN 

where; CP is the command mnemonic 

SN is a temporary child set number 

Output; A set (next available temporary set number) of parent records 

Processing: The parent record ID for each child record ID in the 

input set is placed in the output set. 

3 . 3 . 3 . 2 Generate Children Set 

Purpose: To generate a children set (FLOCON records in ASATS) 

for a set of parent records (DAPTS record in ASATS) . 

Input; GCSN 

where: GC is the command mnemonic 

SN is tlie temporary parent set number 

Output: Children set (whose set number is the next available 

temporary set number) 

Processing: The record pointer address is computed for each 

record ID in the parent set. The addresses for potential children 
records (up to 16 records following the parent records) is searched 
to discover whether children records exist. Each child ID that 
is found is then put into the output set. 



3. 3. 3. 3 Display Data from Two Data Base Levels 

Purpose: To display a set of FLOCON records with selected 

information from the associated DAPTS records, as specified by 
a format (Joint Display Formatted). 

Input: JFSN, FMT 

where: JF is the command mnemonic 

SN is the temporary set number for a set of 
FLOCON records 

FMT is the format ID for displaying data 

Output: Specified set in specified format on report file. 

Processing: The format for displaying data is retrieved. Then 

for each record ID in the input sot, the following actions are 
taken: 

• Get record ID from set 

• Retrieve record and its format 

• Transfer data from the child (FLOCON) record to an output 
buffer according to the display format 

• Generate record ID for associated parent (DAPTS) record 

• Retrieve DAPTS record and associated format 

• Transfer data from the DAPTS record to output buffer according 
to the display format 

• Write output buffer to the report file 
3.3.4 ACCESS CONTROL 

The following new commands, software, and RIMS modifications are 
defined to satisfy access control requirements. Each user will 
have an access control word. It will control which RIMS commands 
he can or cannot use. 


3. 3. 4.1 Add Access Control Word 


Purpose: To add an access control password for the data base. 

Input: S+ 

PASSWORD >XXXXX 
BIT MASK >1110111 

where: S+ is the command mnemonic 

XXXXX is an 8-character access control word 
1110111... is a d-1 -character string identif\ing 
which commands the user having this access code 
can utilize. 

Output: Access code and character string arc stored in data base. 

Processing: A record is generated containing the character string. 

A key is generated by hashing the character string. The record 
is posted to that key. NOTH: The key cannot be reconstructed 

by the display from the expand function. 

3. 3. 4. 2 Delete Access Control Word 

Purpose: To delete an access control password. 

Input; S- 

PAS SWORD > XXXXX 

where: S- is the command mnemonic 

XXXXX is the access control word 

Output: No reply - access code and character string arc deleted 

from the data base. 

Processing: The record posted to the password is deleted and the 

key associated with the control word is deleted, 

3 . 3 . 4 . 3 Modifications to Allow Password Control 

Purpose: To allow identification of a user to RIMS by access 

control word following first begin command. 


Output: PASSWQRD > (prompt to user) 


Input; Access Control password 

Processing: The record associated with the control word is 

retrieved. If the given control password docs not exist, RIMS 
is aborted. 

3 • 3 . 4 . 4 Modification to RIMS Control Rout ine l‘o r Ac cess Cont rol 
Purpose: To prevent execution of unauthorised coniiuamls. 

Output: Message file - 'illegal command'. 

Processing: Before calling the subroutine to process the associ- 

ated command, the character string containing indicators of user's 
authorized commands is examined. If the user is not authorized 
to use the command, the message is output and the subroutine is 
not executed. 

3.3.5 ARITHMETIC OPERATIONS 

A new RIMS command has been included to provide the typical sta- 
tistical and arithmetic operations required by ASATS in the 
ad lioc environment. 

3 . 3 . 5 . 1 Compute Command 

Purpose: to provide for a set of records (1) summation of iden- 

tified field, (2) mean of the difference of two fields, 

(3) standard deviation of the differences of two fields. 

Input: ARSN, Rl'I), ^■N 2 

where: AR is the command mnemonic 

SN is the set number for which all computations 
are to be performed 

RID is the record ID for the record where tlie 
results of the computation are to be stored 
is a field name 
I’N 2 is a field name 



Output: Sum of both fields, moan of difference, standard devia- 

tion of difference, count of the number of records used in mean 
computation, and the count of the total number of records are 
stored in the specified record. 

Processing: Each record in a set is retrieved and processed. 

The following computation is performed for each record. 

• Each field is summed over all records in which both fields 
are not blank. 

• A count of the number of records is maintained. 

• For each record where either field is blank 

• Count of the records is maintained 

• Sum of the difference of the two fields is maintained 

After all records have been processed, the mean and the standard 
deviation of the differences are computed. All computed results 
are then stored in the specified record. 

3.3.6 MODIFICATION TO EXISTING COMMANDS 

In order to implement sta/.dard reports by executing a RIMS com- 
mand file containing the kIMS commands for reports, two new 
capabilities have been implemented. They are: 

• The ability to generate null sets 

• The ability to assign a file by name 

The following modifications provide these capabilities. 


3 ^ 


3 . 3 . 6 . 1 Modification to Reassign File 


Input modifications: The previous syntax was RFIU,EU. The 

syntax has been modified to allow another form: RFIU,EU,FNA. 

where: RF is the command 

lU is the internal unit number 
Ell is the external unit number 
I'NA is the file name 

so that if lU is 0 (zero), then EU is set to the included file 
name . 

Output modifications: None 

Processing modification: If the internal unit is zero, the 

external unit is closed then re-opened with the specified file 
name. Otherwise, processing is the same. 

3. 3. 6. 2 Null Set Option Addition 
Input: ZZOP 

where ZZ is the command mnemonic 

OP is the option: 1 for null sets to be kept; zero for 

null sets not kept. At sign-on, the 
default mode of tlie system will be for 
null sets not to be kept. 

Output; None 

Processing: A flag is set in a common block to indicate the null 

set mode. 


3 . 4 THE PREPROCESSOR 
3.4.1 PURPOSE 


The Preprocessor produces several of the required 
listings of the input update cards and acts as an 
between the unsorted, unedited input form and the 
required for the RIMS data management software. 


audit report 
interface 
form of input 


3 . 




3.4.2 INPUT 

The Preprocessor accepts update cards of all types as described 
in the ASATS Hpeci fications Document, bliC-H()75 (Rev. A), and 
ASATS LACIH Procedure 1 Detailed Design Specification, LHi: 1(1529, 
The cards may be in any order and must include one and only one Q 
card. The input update cards for the Preprocessor make up the 
last of three files read in by the operator before each d;iily 
update and report batch run. (.The first two files are for report 
(generation. ) 


3.4.3 OUTPUT 

The Preprocessor outputs two types of data. The first type is 
the listing of input cards: 

• A listing of all cards in the onler of their input 

• A listing of all cards having invalid card types 

• A listing of all cards rejected as duplicates 

• A listing of all cards submitted for this update run, sorted 

into order by card type. 


The second type of output from the Preprocessor is a set of 
files containing update card images which are combined to drive 
the RIMS system for actual update of the data base. The files 
are : 


• A file of all sets of *, 2, 3 cards, where a complete sot is 
given for any segment 

• A file of *, 2, 3 cards in which only one or two of the cards 
appears for any segment 

• A file of other update cards sorted into the order: 4, 5, 6, 

B. 7. 8. 9. G, II, I, N, J, K, M, T, X, 1] . 


3.4.4 DESCRIPTION OF PROCESS 


The Preprocessor consists o£ a sequence of operations performed 
by special-purpose FORTRAN programs and by calls to the RSX-llD 
system SORT utility program. Data flow for this sequence of 
operations is shown in Figure 3-8. 

The first operation shown, gives two of the input listings and 
separates update cards by LACII! phase into separate files. In 
this operation, cards with invalid type or LACIE phase are 
rejected, and a check is made to be sure there is one Q card. 

The second operation is performed by the RSX-llD system SORT 
utility, to put the cards into order by card type. 

The next operation shown is a separation of cards by type. The 
type *, 2, 3 cards will be sorted by segment number to find those 
segments for which all three are present and which may, therefore, 
be new segments for entry among the DAPTS records. Cards not 
part of a set will be sorted back into card type order with 
* cards first, then 2 cards, then the 3 cards. Cards of other 
types (4, 5, 6, B, 7, •••) are put into another separate file. 

3.5 THE POSTPROCESSOR 
3.5.1 PURPOSE 

The Postprocessor is required because of core space limitations 
on the number of output files tliat can be defined in RIMS. The 
RIMS update task for ASATS writes several logical output files 
into one actual output i'ilc and attaches a flag to each recoid 
to allow the Postprocessor to separate the output files. 



STEP 1 










3.5.2 INPUT 


Input to the Postprocessor is a file of information about updates 
made or attempted by RIMS. 

3.5.3 OUTPUT 

Output from the Postprocessor consists of one file of card images 
to be punched and several files of report listings, as follows: 

• Cards punched (4, 5, 6 cards for each *, 2 , 3 set that created 
a new DAPTS segment record; G, U, and UNLD cards punched for 
each B card that created a new acquisition (FLOCON-record) ; and 
and T card punched from each T-lOO segment J card submitted. 

• A listing of the cards punched 

• A listing of all new DAPTS segment records added 

• A listing of invalid acquisitions (B cards for which no DAPTS 

record has the same segment number) 

• A listing of invalid attempts to modify a DAPTS record (modi- 

fications from *, 2, 3, 4, 5, 6 cards such that no existing 

DAPTS record has the given segment number) 

• A listing of invalid modifications to FLOCON records (no 
matching segment number and/or acquisition date for input G, 

H, I, J, K, M, N, T, U, X, 7, 8, or 9 cards) or a required 
data base field has not previously been set (as required for 
card types H, I, J, etc.). 

• Packet labels 

3.5.4 DESCRIPTION OF PROCESS 

The Postprocessor will read the output file from RIMS and write 
into the proper output file(s) chosen on the has is of a flag 
included with each record from RIMS. See figure 3-9. 
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3.6 ASATS STANDARD REPORTS 


All standard reports identified, as required for ASATS, can be 
produced using RIMS commands (as augmented in section 3.4 of 
this document) and the added output translation function. Once 
a data base has been established as described in this document, 
RIMS provides the functional capabilities required for these 
reports . 

In order to satisfy the standard report and ad hoc report require 
ments using the data base design as described in section 3.2, it 
is necessary to perform output translation for some data elements 
This translation generates the output field value as a function 
of the input field value using a predefined table. 

Three tables are required for the necessary output translations. 
They are: 

• Film products status table as a function of Acquisition Status 
Character CURSl. 

• Computer products status table as a function of Acquisition 
Status Character CURS2. 

• Table indicating crop calendar, ancillary data, and topographi 
data status as a function of the segment status character. 

Two additional data types are required for output processing. 

They are: 

• Data type 5 - Perform output translation using film products 
status table. 

• Data type 4 - Perform output translation using computed pro- 
ducts status table. 

For each data type, the input format specifies the location of 



data to be used for the table look-up. The output format speci- 
fies the location where the table results are to be placed in 
the output record. 

These records have been implemented by building separate files 
containing the necessary RIMS commands for each report. The 
report can then be produced by assigning the file as a RIMS 
command file. The reports are initiated as part of the batch 
run by a "starter” file that is copied to the standard RIMS 
command file. The starter file reassigns the command file to 
the actual report file. 

The requirements for each report have been translated directly 
into RIMS commands. Individual report command files are described 
in section 4. 



4. CONTROL FILES 


This section describes the files which control the operational 
ASATS system: utility command files, batch run control card 

files, and "canned" RIMS command files. Command files used to 
build tasks will be described in section 6, and data files are 
described in section 5. 

4.1 PIP UTILITY COMMAND PILES 

4.1.1 UP.CMD 

This file of PIP commands uses three files from the daily input 
card deck to prepare files for the daily update and report run: 
the date to be on reports, the reports desired, and the updates 
to be made to the data base. The text of this file appears in 
figure 4-1. 

This command file is invoked by the operator: 

MCR>H EL [(ASATS UIC) ] 

MCR> PIP SUP 

The card deck to be processed must contain three files (each 
terminated by the standard PDP-11 RSX-llD end-of-file card) ; 

1. A RIMS HD command for the header date line in reports 

2. A file of PIP commands that copy RIMS report command files 
into successive versions of the file REP.COM 

3. The standard ASATS update cards, including one Q-type card. 
The output files produced are 

1. File DATE.COM which contains the HD command giving the date 
and an RF13;13 command. 

2. As many versions of REP.COM as were specified by the input, 
plus five additional dummy versions to prevent RIMS from 
trying to read a nonexistent file. 


0ATE.C0M»EN0^1Lf 

OATtUOHM/Dl 

OATE.COMiCBl 

0ATr.CCM»RFl5t3.f:0M/AP 

8L0.CMD»EN0EILE 

8l.0.rwoi*/0| 

SLO.C^'O^ENOFILf 

»LO,CHDsf»l 

R|P,COM»FNOF!Lt 

RER,CCH|#/Ot 

•BLO'.CMO 

RER.CnM.ENoritE 

REP.CCM.FNDPILE 

REP.COM.FNOFItE 

REP,COM«fTNOE!LE 

REP,COH»E'^OEUf 

ppEii . cpe»enofilf 

PPPJI ,CPF »#/OF 

PPFH ,CPE«CR| 


Figure 4-1. -The Update Card Read Command File, UP.CMD. 



3. The file PPFll.CRE of ASATS update card images. 

In the process of creating the above files, any files left over 
from previous days are deleted. Deletion of files is always 
preceded by creation of a dummy file (a copy of the empty file 
ENDFILE.;!) so that the delete operation will not give any 
meaningless error messages to the operator. 

4.1.2 LA.CMD 

This file is used by the operator to print packet labels on the 
line printer. The text of this file appears in Figure 4-2. It 
is invoked with the command: 

MCR>PIP 0LA 

The input is the label file created by the Postprocessor, 
P0ST8.ZIP. It is copied to the line printer. 

4.1.3 SAMTn.CMD 

There are two files which can be used to do the daily save of 
the data base. The file SAMT0.CMD saves it on MT0 : and SAMT1.CMD 
saves it on MTl : . The file SAMT0.CMD is shown in Figure 4-3. 

The operator must initialize and mount a tape, and then issue 
a command: 

MCR>PIP 0SAMTn 

The command file copies the DATE.COM file to the tape as a check 
of the date the tape was made, and then copies all the data base 
files to the tape. The command file then gets a directory of 
the tape and saves that directory on disk, prints it on the line 
printer and prints it on the terminal, to assure the operator 
that the files have been saved on tape. 



LPI»*» (1STS.ZIP 


Figure 4-2.— The Packet Label Print Command File, LA.CML). 



UP*Tf»»MTOiA,*M/Ll 

LPf«l.P.TIS 

TIl«L».TrS 


Figure 4- 5. -The Data Base Save Command File, SAMT0.CMD. 



4.2 ASATS.BIS, THE BATCH RUN CONTROL CARD FILE 

The control card file for the daily batch run of updates and re- 
ports is designed to satisfy several criteria which prevent it 
from always being straightforward, namely: 

« It should not give the operator any specious error messages- 
e.g., if a file which may or may not be left over from a pre- 
vious run must be deleted, the message that the file does not 
exist should be suppressed. 

« The operator should interact with the operations as little as 
possible, and his choice of interaction should always be 
clear . 

• Status information should be given periodically to allow re- 
start, if possible. 

• The many files c created during a run should be deleted auto- 
matically, within the run or on the next run. 

Keeping those principles in mind to explain the other "extra" 
operations, the basic required sequence of operations is this: 

• Run step 1 of the preprocessor 

f Sort the separate LACIE Phase update card files into order 
by card type 

o Run step 3 of the preprocessor 

9 Sort the *,2,3 card files into sets by segment number 
0 Run step 5 of the preprocessor to recover complete sets of 
*,2,3 cards 

0 Put the non-set *,2,3 cards back sorted by card type order 

• Append the separate update files into a single file for each 
LACIE Phase 

• Run the ASATS task (RIMS data base update) for LACIE Phase 
3, (Phase 2 updates have not yet been incorporated as an 
automatic operation in the daily run) 


@ Run the postprocessor to convert the single report file from 
the update run into 8 separate files; 6 audit listings, the 
packet labels, and a file of card images to be punched. 

d Run RIMS five times as a batch mode task to produce as many 
as five reports requested for this run. The input data for 
the batch run is all from disk files. The data base is per- 
manently resident on disk and other data input (the date to 
be put onto reports, the RIMS command files that start re- 
ports, and the update cards) are read in immediately prior 
to the batch run (see the description of the PTP command file 
UP.CMD). Much of the output of tlie batch run goes directly 
to line printer spool files. Three of the outputs are left 
in disk files and copied to output media by the operator: 
packet labels are copied to label stock in the line printer 
with PIP command file LA.CML), the newly updated data base 
is retained on disk and a backup copy on tape is made with, 
one of the PIP command files SAMT0.CMD or SAMT1.CMD. And 
cards arc made from the file PUNCH.ZIP by using the utility 
program CRDOUT to produce a card- image tape. The "control 
card" file ASATS.BIS is actually a disk file of control card 
images. The batch run is initiated by the operator with the 
batch command: BAT ASATS (ALT) (The alternate mode key in- 
stead of carriage return allows MESSAGE card information to 
appear on the operator console) . 


The complete text of ASATS.BIS is shown in Figure 4-4. 


«J0B/mAMP«A8AT8H/I.tMITb«99/mCP 

8M|8$ACf. A8ATI BATCu STRBAM VERSION H flO JUNE 1977), 

SMiSSABE EIXED TO 8ft»T PUNCHEO CAROS INTO OROfcR BV TYPE, 

SHE8SA6E BE SURE VOi'i HAyEl 

SME8SAGE READ IN CARD DECK, 

SMgSSASE i WITHi PIP #UP ) 

SME88A6E IN CASE OF TROUBLE, CALLi 

SMISSAGI . JOE gvERETTE S55-61U (DAYS) OR 554-8660 (NIGHTS) 

SHCSSACE OR DAVE gMiTH 133-63)1 (DAYS) OR 462-0604 (NIGHTS) 

SHgSSAGE OR JOHN pOQN 443-6427 (DAYS) OR 461-0339 (NIGHTS) 

SME68AGE IF CARDS NpT O'.K,, ABORT THIS RUN AND RESTART 
8MESSAGE WITH ANOTHrR BAT ASATS AFTER READING CAROS. 

8MCR PIP 0UM,TE8«CNnFILE 
»MC R P I P _kP J.«,t ^Tf 8 

IME88AGE/WAIT NOW, tVPE IN CONfCR) TO CONTINUE, OR ABO(CR) TO ABqRT. 
SMCR PIP LP|**’.TES|:/LT 
IMESSAGE start PREPpOCESSOR 
S 1 CLEAN UP files 
IMCR PIP 

OyMY.TfSjENOfTU , . . . 

ft.TEaiw/OE 

S 1 STEP t READS PPclT.CPE AND WRITES OUT THE FOLLOWING: 

8 I PPF142 and PPrl43 (PHASE ? AND 3 FOR LATER PROCESSING) 

8 I OTHER FILES Tft LINE PRINTER 

S 1 SORT OPERATION WILL ALWAYS HAVE INPUT AND ALWAYS PUT OUT 
3 1 SOMETHING IF I? RUNS SUCCESSFULLY. 

8RUN STEPiVfsV 
SMESSAGE START SORT 

SMCR SRT PPF242,TE8;pPFi42.TE5/SIZElSO,DL8PEC,SOR 
S I CAN NOW SAVE SpACE BY REMC^vINq INPUT TO THAT SORT, 

SMCR PIP PPF142.TE8;i/DE 

SMCR SRT PPF243.TE8,PPFl43.TES/SIZf I60,DLSPEC.80R 
SMCR PIP PPM43,TE8 i 1/0E 
S I SET UP NOW FOR flTEPi'. 

S i STEP 3 WRITES TwO FILES FOR FACH LACIE PHASEl 
S I PPF35(2 AND 3) OF NON-w, 2, 3 CAROS 
8 I PPF33(2 AND 3) OF *, 2, 3 CARDS 

1 1 ALL four must EiTST IF NO ME88AGFS ARE TO 6£ GIVEN, 

SMCR Pip 

PPFSSZ.TESbENOFILE 

PPFSSS.TESiENDFlLE 

PPF392,TESb|NDFILE 

PPFSBS.TESbENOFILE 

8RUN STEPS. T8K 

SMCR PIP PPF242.TE8,%/DE 

SMCR PIP PPF243,TE8.,'w/DE 

Figure 4-4. -The Batch Run Control Card File, ASATS. BIS. 



SMrssAcr step } o"f pPE"p‘RdcYf80P finished 

S l BEFORE DOING THp SORT, PUT UP A OUMMV OUTPUT FILF FO» IT, 

SMCR PIP f^PF«2P,TE8iFNDFlLE 

SMCP 8RT PPFP2P.TE8.PPF5SS,TE8/8TZEl80/KEY8lCN«,«lCNl.S0 

i I NOW 'clKan UP iNSuf files" TO that Sort# and 
8 1 UP dummy outputs for STFP 5. 

SMCR PIP 
PPFSSS,TESl*/DE 
PPF8SP,TF8«EN0FILE 
PRE5|P,T|8«EN0FILE 
>PF57P.TE8»FNDFILE 
SPUN STEPS. TSK 
SMCR PIP PPF«2P.TES,'*/bF 
SME88AGE STEP 5 FINtSHFO FOR PHASE S 

S 1 NOW SORT THE *,5.1 NON-SETS BACK INTO CARU-TVPE ORDER, 

S I FIRST# PUT UP A DUMMY SORTEO OUTPUT FILE, 

SMCR PIP PPFfcSl.TESiENDFILE 

SMCP 8RT PPF65S,TFS-PPFSSP.TES/SIZEI0O/KEYSICN1 ,80 

I I NOW delete Input to that sort and concatenate all the update files. 

SMCR PIP 

LP8BPPF5TP.TE8 

PPF5TP,TE8l*/Oe 

PpF55P.tESl*/DE 

PHASES, TE8bPPF83P,TfS/RF 

PHASES. TF8«PPF65S,TpS/AP 

PHASES, TE8»PPF35S.TfS/AP 

ppfssp.tesbenofile 

PPF5SP,TESl*/0E 

PPF65S.TES|*>6e 

PPFS5S,TE8l*/DE 

PPFa?P.TE8»ENDFlLE 

|MCP 8RT PPFR2P,TESaPPFll2.TES/8lZEl80/KEYS»CNa,«lCNl ,80 

I J NOW CLEAN UP iNpllT TO THAT SORT AND GIVE OU^My OUTPUT FOR STEP 5, 

SMCR PIP 

RPFSSI.TF8»*/DE 

PPFfSP,TES*ENDFUE 

PPF55P.TE8»ENdFILE 

PPF57P.TESPEN0FILE 

SPUN STEPS. TSK 

SMCR PIP PPFR2P,TES.*/0E 

SMI88AGE STEP 5 FINtSHEO FOR PHASE 2. 

8 I SORT *#2,3 NON-fFTS BACK INTO CARD-TYPE ORDER, 

S 1 FIRST# create a dummy SORTED FILE, 

SMCR PIP PPF6?2,TES,EN0FILE 

SMCR 8RT PPFSSP.TES.PPFBSP’.TES/SIZElBO/KEYSiCNl.ao 
*MCR SRT KH^A> 52 ,Tt»«i?»Hl» 5 >sr, t f lou/r't r M .fU 


Figure 4 -4. -The Batch Run Control Card File, ASMS. BIS. (cont) 



I I DELETE IMPlJT TO THAT lORT, CONCATENATE UPDATE FILES, 

IMCR PIP 
PPF55P.TF8M/0E 
LPI-PPF9TP.TE8 
PPF57F.TE8M/DE 
'P PHASEl.TE8BpPF8lP.TrP/PF 
PHA8E2.TE8»PPF65?.Tr8/Ap 
PHA'SEa.miWSSj.TM/Ap 
-H PPFSIP.TESbENOFILE 
PPF8SP,TE8i*/DE 
PPF652.TE8IA/0E 
"P PPF582,TE8l*/0E 

I 1 ALL FILES APF NnW PLFANFD UP AND UPDATES APE IN 2 FILES, 
81' SEPARATED BY P^ASFi PHASES. TE8 AND PHASE2.TF8. 

A 8ME88AGF PHASE 3 UPRaTES WILL Nf)W BEGIN, 

SMCR PIP 

PPFJ8S.TE8bPMA8E1,T»8/Rf 
F0R012,0AT»EN0FII E 
FOR012,OAT|*/DE 
Fa»6i2,DAT«EN6FIiE 
FOROCT.DATbENDFUF. 

FOPOOT.OATia/OE 

IHESSAGI this IS YOmP LaST CHANCE TO STOP UPDATES (CON OR ABO), 

SMCR PIP LP|b*.TESi;/LT / 

SME88ACE/WAIT fiF Yflll GO PAST THIS POINT, YOU CANNOT RESTART), 

SMCR PIP i:R|iA.TE8»;/LT 

SPUN ASAT8.TSK 

SMCR PIP LO,TES»a,*;*/LI 

SME88AGE PHASE 3 UPDATES CONPLFTFO, 

♦* 8MCR PIP 

RM*,P08»rNOFILE 
flM?,P08l*/DE 
•»' RMI.P08 bFOP012.DAT 

oum.zipbenofile 

*,ZIPI*/DI 

SMISSAGE PREPARE OUtPUT REPOPTS, 

SPUN P08TP.TSK 

SMCR PIP CARD8’.TES»pIINCh’.ZIP/RE 
»' SMCR 8RT PUNCH, ZTP«?ARDS'.TES/SIZE|B0/KEYSICNI,*0 
' SMCR PIP LO.Te8«*.*i'*/L I 

SMCR PIP PUNCH, ZlP«nATE.COM/AP 
SMCR PIP LPIBa.ZIPi; 

S J START THE OTHER DAILY REPORTS, 

SMCR PIP UNITS. SATIpObBATCH, SAT 
» SMCR PIP BAT.COM.ENpFiLE 
SMCR PIP BAT,COMm/qE 
SMCR PIP BAT,COM«REp’.COMM/RF 
SRUN RIMSl.TBK 

Figure 4-4. -The Batch Run Control Card File, ASATS.BIS. (cent) 
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$MCR 
SMCR 
SHCR 
SMCR 
SMCR 
SRUN 
SMCR 
SMCR 
SMCR 
SMCR 
SMCR 
SRUM 
SMCR 
SMCR 
SMCR 
SMCR 
SMCR 
SPUN 
SMCR 
SMCR 
SMCR 
SMCR 
SMCR 
SRUN 
SMCR 
SMCR 
SMCR 
SMCR 
SMCR 
SMCR 
SHCSSAGr 
SMESGAGf 
SMCSSAGE 
SME88AGE 
SME8SAGE 


PIP 

PIP OUM.SHI.rNSFIl.F 

PIP *.5HIM/DE 

PIP BAT.COM|*/gF 

PIP BAT,COM«Rtp'.criMi?/Rr 

RIM82.TSK 

PIP LP,TC8«*.*;*/LI 

PIP OUM.SHI«ENnFTLF 

PIP *,SHIi*/DE 

PIP BAT.COMm/qF 

PIP 9AT.C0M«Rf^'C0mi3/RF. 

RIMS1.T8K 

PIP LO,TES«#,*it/Ui 

PIP OUM.SHI«FNnFILF 

PIP *,8Hn*yDE 

PIP 8AT.cnM»*/SF 

PIP BAT,C0M«REp'.C0mi4/RF 

RIM84J.T8K 

PIP IR.TE8«*.*,’#/L I 

PIP DUM.SHI.ENpFlLF 

PIP *,8HIM/DF 

PIP BAT.COMm/pF 

PIP BAT,COM«REp’.cOmi5/»F 

RIMS54T8K 

PIP 10*TE8»*,*|«»/L T 
0!IM,SHI«EN?;FaF 
*, shim/de 

BAT,COM|#/Sf 
UNITS, SAT|5o/nF 
LP|«PHASE?Sm/I.I 


PIP 

PIP 

PIP 

PIP 

PIP 


A^ITS PHASF ! BATCW UPDATES AND REPORTS * 


END OF 
PFNFMRER 


TDI 


make cards fUSE 
FILE 


CRDOtiT ON the 


* 

* 

* 


S' 

• > 

SMESSAGE 

* 

ANn 

make labels (LOAD labels INTO 

A 


SMESSAGE 

* 


printer and ou pip fla 

) ♦ 


SMESSAGE 

* 

ANft 

8AVF (210,004J ONTO TAOE 

A 

^ » 

SMESSAGE 

* 


( HEi rs.si 

A 


SMESSAGE 

* 


INI MTPIP3 OATfc VUIC* (210#00«) 

A 


SMESSAGE 

* 


mdu mtoi/ovh 

A 

S ' 

SMESSAGE 

* 


HEL f?10,00«J 

A 


SMESSAGE 

* 


PIP fsamtoi 

A 


SME88AGE 
SMES8AGE 
SMESSAGE 
SMCR PIP 
SMESSAGE 


* rASTFN THF DTRECTOPV TO TH£ TAPE ) * 

* this is tMF end of the ASATS phase 1 BATCH RUN, * 


LPi«A,TFSi.;yLI 

NOW load 5>ART paper INTO THf PRINTER AND 
SMES8AGE/WAIT TYPE tN CON (CR) TO PRINT REPORTS, 
SMCR PIP LP|»A,TF8i;/LI 
SEOJ 


Figure 4-4.- The Batch Run Control Card File, ASATS, BIS. (Concluded) 
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4.3 SORT UTILITY SPECIFICATION FILE DLSPEC. SOR 


This file controls the sort utility (SRT) for the two sorts of 
update card files which occur between step 1 and step 3 of the 
preprocessor. The purpose of the sort is to put the cards into 
order by card type Ccolumn 2) for proper order of processing of 
two or more updates on a single segment or acquisition, and to 
be sure that duplicate cards are detected (because after the 
sort, duplicates will be together in the file). The ordering of 
card tapes is effected by a "force" (F in column 7 of the des- 
cription of the type field) which, in effect, changes the collat- 
ing sequence only in that field. Otheir fields are sorted on the 
standard ASCII collating sequence. 

The text of DLSPEC. SOR is shown in Figure 4-5. 



00 

HSORTR 

90A t 60 HEADER CARD 

01 

Frc 

2f5* 

OS 

frc 

2*2- 

OS 

fn 

. 223- ^ , 

oa 

FFC 

2S«- 

06 

FFC 

24»5- . _ 

06 

FFC 

256- 

_._.07 

FFC 

267- 

on 

FFC 

2P6- 

06 

FFC . .. . 

279- _ „ .. 

10 

FFC 

286- 

11 

FFC 

■ 20G- . * 

IS 

ffc 

2RH- 

13 

FFC 

2HI- 

U 

FFC 

2TJ- 

15 

FFC . 

2MK. 

16 

FFC 

2JM- 

17 

FFC; 

2KN. 

16 

FFC 

2MQ. 

16 

FFC 

2TT- 

SO 

FFC 

2XU- 

21 

FFC 

2(JX- 

2S 

FNC 3 

60 

23 

FOC 1 

60 


Figure 4-5.- The Sort (SRT) Specification File, DLSPEC.SOR. 



4.4 ASATS/RIMS COMMAND FILES 


An ASATS/RIMS command file is a series of RIMS commands. Report 
files tend to be repetitive. The most frequently used command 
files represent a query report situation where a lengthy series 
of commands would otherwise have to be manually input interactively 
each time the specific report is desired. The command files, 
therefore, provide for consistency of reports and, perhaps more 
importantly, for convenience to request an already debugged 
stream of commands to the ASATS data base. The command file 
approach also offers convenience in that the files may be used 
as often as required in either batch or interactive mode. Other 
command files may be used for controlling processing sequences 
such as the Update Control File (RM4.COM). 


4.4.1 RM4.COM - AN UPDATE CONTROL FILE 


The following is a listing of the standard card file update con- 


trol commands : 

Bcononot 

RF0» 

RF12* 12 
RE 

RFC,l?»FoR012,nAT 

RFO, 1 1 ,0B0|PPF555,TfS 

RF11»U 

UP 

UP 

UP 

up 

UP 

UP 

UP 

UP 

UP 

UP 

up 

UP 

up 

UP 

up 

UP 


UP 

UP 

UP 

UP 

UP 

UP 

UP 

FN 


NOTE: The RE and UP commands 

as used herein are 
special ASATS commands 
to read and interpret 
the Procedure 1/normal 
ASATS processing type 
code and to update the 
ASATS data base. Thus, 
the RE and UP commands 
as used here should not 
be confused with the RIMS 
commands of the same 
mnemonic ; i . e . , ... 

RE for "Restructure” 

UP for "Unpost". 



and 


4.4.2 OP13.COM - OPERATIONS STATUS SUMMyXRY OP SEGMENTS IN THE 
DAPTS DATA BASE REPORT COMMAND FILE 


The following list represents the standard report generating 
commands to produce the frequently requested OPS Status Summary 
of Segments in the DAPTS DB: 


BE 

8KC0U^TR#CPLINTRZ 

Rrip,io 

’ H01,l 
HOI# 

H02, 

T5 DB 

RFO, 12,OBO|04TE.COH 

Rns. J2 

Hpl ,0 
HD2# 8EG 
3 BH BW (1 

HD?, ^0, CHTRY RG 70Mr STP 
be open close topo c»np a^cl 
HD l, 

PPl 

EM 


LACIt phase TII 

DPS STATUS summary OE SfcOS IN '• AP 


G S'* I BW 1 2 i tio- 

LAST 

D V PC TY OPEN CLOSE OPEN CLOSE OPen CLO 

change 


This report command file additionally illustrates use of the 
report header commands available to the user plus demonstrating 
how another conuntmd file may be called to become an integral part 
of this command stream (see line RE0 , 12 , DB0 : DATE . COM) . 


4.4.3 OP23.COM - OPERATIONS STATUS SUMMARY OF ACQUISITIONS 
COMMAND FILE 


The following list represents the standard report generating 
commands to produce the frequently requested OPS Status Summary 


of Acquisition report (similar to the report 

BE 

8KBH PBw P 

PFr?.io 
HDl , 1 
HO?, 

OUTSiTlONS 

RPO, t?,OBOiOATF.fnM 

RF13, 1? 

HDl, 6 

HD?, SEG ACQ B W taPF F 

R W CAM CA 

HO?, ^0 date P V nD f pg pc gsfc 

H 1 JCK MCVBPTG LSD 
JF1,70 
EN 



commands of par. 4.4.2). 


LAClt PHASE il 
OPS STATUS SUPMARf OP Au 


comment 9 G 


4.4.4 POLIST.COM - PACKET ORDER LIST COMMAND FILE 


The following partial list illustrates a quite lengthy, but 
mostly repetitive type of report generating commands to produce 
the daily requested packet order list. This redundancy is 
fairly obvious in the report header commands; however, note 
that the data set isolation command (SKPC 2, SKPC 3, etc.) 
changes with each iteration. The purpose here is to provide 
standardized format for a group of reports which operate 


sequentially upon different data sets. 

RM2, to 
1ST 

»r0, t?, PATE, COM 

RF13.1? 

HOI , 


HOI, 

PHASE III 

US 

PC? 

HCTJ , 





HDl, 




REG zOME STR e 

h02. 

CRD 

SEC LPI 

aCR 

TX 

REC 

CAMS/LPDL 

COMMEMT 

HO?, 


MO 

date 

w 

ATE 





Pfl? 

,T 




SKPC 


? 



cct 





|H?, 

ATCnHP.NE, , 

PACKrF 

# f B • f 

RF12 

,to 




JF3, 

90 




805, 


total acg 

IiTSTtIO^S 


BE 

BFt2,tO 

HD2,t 

1ST 

PFO, 1?, DATE.COM 

■■■R'Fn/iJ''* 

HDl » 

HDl# PHASE in US PCS 

HDl, 

HOI, 

HD?, ORD SfG LPI AC<5 PFD 
TX' '^IC' CAHf/UPOl comment 
H02, HO DATF 

ate 

RFIP.T 
SKPC i 

set 

SHE, AICOMP.NE, .PACKrF.FQ’. 

PF1?,10 

JF3,P0 

8C5,Afe, TOTAL ACQpTSTTlOHS 



DATLV PACKET OPOEk U 


w CHT LAST DLL 

V CHMG U 


DAILY PACKET URLEP U 


^ CHT last DLL 

Y CHNG ) 


ORIGINAL PAGE IF 
OF POOR QUALITY 


5. ASATS/RIMS FILE USAGE 


This chapter describes the data files used in the daily opera- 
tions of the ASATS interactive and batch mode systems. The 
control files which control sequences of utility or batch oper- 
ations have already been described in chapter 4. Command files 
for building the system (indirect task builder files, etc.) will 
be described in chapter 6. 

5.1 THE RELATION OF INTERNAL FILE DESIGNATIONS TO EXTEPNAL 

^ 

Most of the tasks in the ASATS/RIMS system have a flexible re- 
lation between internal unit designations and external file 
names that can be varied at load time or during a run, rather 
than being fixed by default FORTRAN complicr and/or task build- 
er assignments. This generalized relation is built from two 
independent relations on three independent sets of designators: 
a relation of fixed internal designations to external logical 
unit numbers, and another relation established between those 
logical unit numbers and system file names (device: name, type; 

version). The first relation is established by an array of 
logical unit numbers read by the program at the beginning of a 
run and possibly changed again during the run. The second re- 
lation is established by a call to the system subroutine ASSIGN, 
and can also occur either at the beginning of a run or during 
the run. The complete relation is the composition of the two 
relations: (read) (ASSIGN) device: 

logical file name. 

internal ^ unit — -> type ; 

variable number version 

(RF n,m) (RF0,m, name) 

The RF command to RIMS can be used in its two different forms 
to alter either relation, as shown above. The relations are 
both established at the beginning of a RIMS run by the sub- 
routine UNITS, which always reads a file UNITS. SAT. That file 

i ^ 


contains one record of logical unit numbers to establish the 
first relation, and five more records that give a unit number 
and a file name to establish the second relation. One version 
of the file UNITS. SAT is permanently on the disk and will be 
picked up for interactive runs to establish command file input 
from the user terminal TI:. A batch run will precede the RUN 
of RIMS by a copy operation from the file BATCH. SAT to a new 
version of UNITS. SAT. The batch run of RIMS will therefore 
supersede the usual interactive command file from the TI: with 
an assignment to the disk command file. That file can contain 
RF commands which will further alter either relation. It should 
be noted that the form "RF0,m,name" will close any file already 
associated with logical unit m and re-open m. This means that 
file m will be positioned at the beginning of the new file. 

This provides a means for using one command file several times. 

It could also cause an infinite loop if the command file re-opens 
itself. It also allows run-time manipulation of command or data 
files. A file of commands could conceivably be written as a 
report file, closed and re-opened as a new version of a command 
file. Or, a report file could be created, closed, re-opened as 
a data input file, and used to update the data base. 

The tasks of the preprocessor and the postprocessor and the 
ASATS utility tasks CONTAP and JJ were all built with similar 
file-assignment capabilities. Each reads its own file, with a 
file type ”IUN", at the beginning of a run to establish both 
logical unit numbers and file names. These tasks do not change 
file assignments later in execution. 


5.2 FILE TYPES USED IN THE ASATS SYSTEM 


Table 5-1 lists the file type mnemonics used in the ASATS system. 
Some of the file types are standard RSX-ll-D type conventions. 

5.3 BATCH RUN DATA FILES 

The data files used in the preprocessor are named with 5- or 
6-character names. The first 3 characters are always "PPF" 
and the next two digits indicate, respectively, the step of 
the preprocessor which uses the file and the logical unit number 
in the program. A final digit "2" or "3" is used if there are 
two similar files for the two LACIE phases. Sometimes the final 
digit is replaced by the letter "P" to indicate that one file 
name is used in two runs of a program for the t\\ro LACIE phases. 

The contents of these files are described in table 5-2. 


TABLE 5-1.- MEANINGS OF FILE TYPES IN ASATS SYSTEM 


File type 
. (blank) ; 


. BIS ; 

.CMD; 

.COM; 

.CRE; 

. DAT ; 

.lUN; 

.POS; 

.Rn; 

( . R1 ; , . R2 ; , • • • ) 
.SAT; 

. SOR; 

.TES; 


.TSK; 

.ZIP; 


Usage 

1. Report "starter” files, usually contain- 
ing RIMS commands: BE, password, and an 

RF to the command file (same name, type 
COM) that produces the report. 

2. Also used as the file type for ENDFILE 
and BLANK (two empty files used to create 
dummy files) . 

Batch input stream 

System utility indirect command files 

RIMS "canned" command files 

A card- image file from the card reader 

Data files (FORTRAN default type) 

Unit-name assignment files (as described in 
section 5.1) 

The input to the postprocessor 
Data base files 

Unit assignment files for RIMS (see 
section 5.1) 

A file for the system sort utility (SRT) 

Update card image and listing files in the 
preprocessor 

Task-built executable modules 

Output print label, or punch files from the 
postprocessor 




TABLE 5-2.- CONTENTS OF BATCH RUN FILES 


File Name 
PPFll.CRE 
PPF13.TES 

PPF142.TES 

PPF143.TES 

PPF16.TES 

PPF17.TES 

PPF18.TES 


PPF19.TES 


PPF242.TES 

PPF243.TES 

PPF332.TES 

PPF333.TES 

PPF352.TES 

PPF353.TES 


Content 

The input to step 1 o£ the Preprocessor. 

The unsorted listing o£ input cards with record 
count. 

The LACIE Phase II cards, with a Q card. 

The LACIE Phase III cards, with a Q card. 

Input cards with invalid type found by step 1 of 
the Preprocessor. 

Cards found by step 1 of the Preprocessor to have 
invalid LACIE Phase. 

Cards found by step 1 of the Preprocessor to have 
some non-blank character in columns which step 1 
checks for blanks. The images fed to RIMS will be 
forced to blank in those columns. 

A file produced by step 1 of the Preprocessor, con 
taining counts of cards and other statistics from 
the first reading of the update cards. 

Input for step 3 of the Preprocessor (Phase 2 ) 

Input for step 3 of the Preprocessor (Phase 3) 

The output from step 3. It contains all the *, 2, 
and 3 cards with LACIE Phase = 2. 

The output from step 3. It contains all *, 2, and 
3 cards with LACIE Phase *= 3. 

All Non-*, 2, or 3 cards put out by step 3 of the 
Preprocessor for LPI - 2 . 

All Non-*, 2, nor 3 cards put out by step 3 of the 
Preprocessor for LPI = 3. 


TABLE 5-2 Concluded. 


File name 
PPF34.TES 

PPF38.TES 

PPF42P.TES 

PPF53P.TES 

PPF55P.TES 


PPF57P.TBS 

PPF653.TES 


Content 

A listing of all input cards sorted by type (or as 
received by step 3 of the Preprocessor.) 

A listing of invalid duplicates found by step 3 of 
the ASATS Preprocessor. 

The input file for step 5. 

Output from step 5. It is the file of complete 
sets of 2, 3 for a single segment. 

Output from stop 5 of the Preprocessor. It is the 
file of all 2, and 3 cards which do not fall into 
complete sets for a segment. 

The listing file of step 5 of the Preprocessor. 

Non- set 2, 3 found by steps 5 and sorted back 
into card type order: * cards, then 2 cards, then 

3 cards. 


6. ASMS EXECUTABLE TASK DESCRIPTIONS 


This chapter describes ASATS program sets at the task level. 

There are three types of tasks in the ASATS system: data base 

manipulation tasks, batch run edit, audit and report formatting 
tasks (pre- and post-processor) , and utility tasks used to build 
or pack the data base. The tasks are listed by type in table 6-1. 

6 . 1 TASK BUILDER COMMAND AND OVERLAY DESCRIPTION FILES 

the ASATS tasks are each built with an indirect command file for 
the RSX-llD Task Builder. Each command file has the same name 
as the task, and file type ”.CMD.". Two of the ASATS tasks, 

ASATS. TSK and RIMS.TSK are built in overlay form, and the respect- 
ive command files refer to Overlay Description files ASATS. ODL 
and RIMS. ODL. Listings of .CMD and .ODL files are included in 
Attachment A to this document. 

6.2 ASATS TASK EXECUTION INSTRUCTIONS 

Most of the ASATS tasks are well documented in terms of user 
application in the ASATS and RIMS user guides. Two additional 
tasks were created expressly for ASATS and have no direct rela- 
tion to RIMS. These tasks were used to manipulate files prior 
to the initial load of the data base transferred to us on tape 
from COMSHARE. The tasks have been retained because there is a 
continuing need for utilities to read foreign tapes and break 
down large sequential files into smaller pieces. These two tasks 
are described on the following pages. 




TABLE 6-1.- ASATS TASK FUNCTIONS 


Task type 

Task name 

Function 

Data Base 

ASATS. TSK 

Updates the data iiaso in the batch run. 

Management 

RIMS.TSK 

(a subset of RIMS) 

Interactive data base update, and 
report generation in both interactive 
and batch inodes. 

Edit and 

STEPl .TSK 

Makes first pass over the update cards 

separate 


and separates them by LACIE Phase 

updates ; 

STEPS. TSK 

Separates *, 2, and S card types from 

produce 


all other types; inserts dates from 

report 


the Q card. 

listings 

STEP 5. TSK 

Finds complete sets of *, 2, 3 cards 
for a segment and separates the sets 
from individual *, 2 , 3 update cards. 


POSTP.TSK 

Separates output from the update task 
into separate listings and punch files. 

Utilities 

CONTAP.TSK 

Reformat a sequential data base file 
in preparation for loading by RIMS. 


CR. TSK 

Create direct -access files for use as 



a data base. 


CREATE. TSK 

Initial creation of a data base. 


vJJ.TSK 

Copies selected records from one 
sequential file to another. 


NEWFILE.TSK 

Builds new files for an empty data base 


PFl .TSK 

Pack data base files .R1 and .R2. 


PF2.TSK 

Pack data base files .R3 and ,R4. 













TASK DESCRIPTION 


Task Name: CONTAP 

Purpose: To read and reformat a sequential file to prepare it 

for loading into a data base. The reformatting is 
generalized, table driven, and programmable. 

Setup Required Before Run: 

• Files Required: CONTAP. lUN (which specifies other file 

names) 

Control table file (as unit 3 in CONTAP. lUN) 
Input and output files written by the 
control file. 

• Other: Can mount a tape as an input file, if desired. 

Run Instructions: 


• Interactive Mode: The user must make available a reformat 

control table in one file to be read by 
CONTAP and put the name of that file 
into CONTAP. lUN along with the names of 
any input or output files to be processed 
by the reformat table. The reformat 
table is a sequence built from the follow- 
ing operations: 

a. Read a file to the input buffer and 
skip next table row unless end-of- 
file. 

b. Move field from input buffer to out- 
put buffer. 

c. Convert characters from EBCDIC to 
ASCII. 

d. Check field for non-numeric and skip 
next row of table if numeric. 



e. Write out the output buffer. 

f. Jump to row N of the table. 

g. Stop. 

There are several other possible opera- 
tions that were specifically built for 
conversion of data from COMSHARE formats 
to the new PDP-11 ASMS formats. A 
detailed description of the parameters 
required in each table row is found in 
the program listing. 



TASK DESCRIPTION 


Task Name: JJ 

Purpose: To break a sequential file into smaller files. 

Setup Required Before Run: 

• Files Required: JJ.IUN, which must specify an input file 

name for unit 2 and an output file name 
for unit 1. 

Run Instructions: 

• Interactive Mode: MCR>R11N JJ ALT 

ENTER START AND END RECORD NUMBERS 
AND RECORD LENGTH IN 315 FORMAT 
_80 



JJ--STOP 

(The above run would copy the first 12 
records from the input file to the out- 
put file with a record length of 80 
characters) . 

Output Files: The output file is selected by the JJ.IUN unit 

assignment file. 


7. NEW AND MODIFIED PROGRAMS 


This chapter contains the as-built design details of individual 
programs (main programs, functions, and subroutines). Included 
are all new programs built especially for ASATS, plus programs 
from the RIMS system which had to be modified for the ASATS 
application. 

For documentation of those RIMS programs which have remained 
unchanged, refer to the RIMS Maintenance Document (LEC-9566, 
October 1976) . 

Complete listings of the ASATS program source files arc given in 
Attachment B to this document. 


Name : 


ABORT (preprocessor step 1) 


Purpose: 

Linkage : 

Input Description: 

Output Description: 
Process Description: 


If two different Q cards exist, then this 
routine will abort the job. 

• Calling sequence: CALL ABORT 

• Common blocks used: UNITS 

• Subroutines or functions used: EXIT 

• Files used: Logical Units 4, 5, 10 

Unit numbers from array TUN - logical unit 
numbers for the listing file and output 
data files. 

Update card files 4 and 5 are erased. 

A check of the count of Q card images is 
made. If Q-type count is not exactly one, 
the job will abort sending ABORT messages 
to the operator's console and the line 
printer file. Units 4 and 5 get rewound 
and have a file mark written into them. 
This prevents making any updates to the 
data base. 


Name; 


ABORT (preprocessor step 3) 


Purpose: 

Linkage : 

Input Description: 
Output Description: 

Process Description: 


To prevent making a data base update when 
the update card file is pathological, 

• Calling sequence: CALL ABORT 

• Common blocks used: UNITS 

• Subroutines or functions used: EXIT 

• Files used: Unit 7 

Listing file unit number in IUN(7) 

A banner message on the print file and a 
message to the operator that the update 
run is to be aborted. 

A FORTRAN write statement and a PAUSE 
message . 



Name ; 


ACCNO 


Purpose : 


Linkage : 


To produce a binary accession number 
(record ID) corresponding to a character 
string. 

• Calling sequence: 

number * ACCNO ( string , start , length ) 
where 

number is the output value, 

string is a character string array, 

start is the starting character position, 
and 

length is the number of characters to be 
converted 

• Common blocks used: None 

• Subroutines or functions used: INDEX, 

INPARM 

• Files used: None 


Input Description: Start and length should be typed INTEGER*4. 

String should contain a string of characters 
that is either: (a) two strings of digits 

separated by an "0", or (b) a single string 
or digits terminated by either the end 
of string or by a non-numeric character 
other than 



Output Description: 


» 


The output is in double -word (INTEGER*4) 
form and is, for a single number, the 
binary value of the number. For the 
double-number form of input, int 1 § int 2 , 
the value of int 1 is put in the second 
output word, with value of int 2 in the 
first word. 


format 

output word 2 

output word 1 

integer 

zero (or overflow) 

value of integer 

int 1 @ int 2 

value of int 1 

value of int 2 


Process Description: Look for the and then convert one or 

two integer parts. 



Name: 


APSEL 


Purpose; 

Linkage: 

Input Description: 
Output Description: 
Process Description: 


Same as SELECT, except that an empty set 
will be selected independent of the 11 
(retain empty set flag) status. 

• Calling sequence: CALL APSEL 

A Common blocks used: SYSCOM 

• Subroutines or functions used: LOCATE 

• Files used; U(3), U(4), U(7) 

See SELECT In the RTMS Maintenance Document 


See SELECT 
See SELECT 



Name : 


Purpose ; 

Linkage : 

Input Description: 

Output Description: 
Process Description: 


ASN 

Assigns file RM4.COM to a specified unit. 
Note: Subroutine exists in order to pro- 

vide better control of position of system 
subroutines in overlays. 

• Calling sequence: CALL ASN (FN) 

• Common blocks used: None 

• Subroutines or functions used: None 

• Files u'-ed: Unit specified on input 

FN contains the unit assignment on file to 
be assigned (RM4.COM). 

None 

File RM4.COM is assigned to specified unit. 



Name ; 


AUDATE 


Purpose : 


Linkage : 


Input Description: 


Updates data base front set of input cards. 
Specific update operations are a function 
of card type (specified in second character 
of each card) , data base format, and the 
input format. The input format and data 
base to be used are also a function of the 
card type. 

• Calling sequence: CALL .\UDATE 

• Common blocks used: SYSCOM, SY2C0M, POT 

• Subroutines or functions used: GETREC , 

LODFMT, AUREC, CHFLD, APSINT, AUPOST, 
APSTUP, SUBSTR, KOMSTR, APvSCNT, SETOUT, 
XXOHT, ENDAT, GETCLD 

• Tables used: Processing Description 

Table (PDT) which contains card type 
versus type of record ID generation 
and the category type table. The bio • 
window table from segment record. 

• Files used: Units 1, 2, 3, and 4 are 

updated. Units 5, 6, 9, and 10 are 
scratch files. ASATS cards are on the 
RIMS data file. The RIMS message file 
is used for ASATS postprocessor data. 

• Command: Processing is begun by a UP 

command 

• Status and tracking input cards: Any of 

the 21 types of ASATS update cards 
(except Q cards) are processed sequen- 
tially until an EOF. 


Input Description; 
(continued) 


Output Description: 


Process Description: 


• EOF: Processing of an input file is 

ended by a blank card (inserted by the 
preprocessor) or by actual end-of-file. 

Besides updating the ASMS data base the 
following information is recorded sequen- 
tially on a file. 

• Rejected input cards 

• Required DAPTS record does not exist 
(for *, 2, 3, 4, 5, and 6 cards) 

• Required FhOCON record does not exist 

• FLOCON record has not reached required 
state for particular type of card. 

• Accepted input cards which create new 
DAPTS records. 

• Punch cards 

The required processing is a function of 
card type. Card types are categorized as 
foi ows : 

• Category 1 — card type 2 

• Category 2 - card types *, 2, 4, 5, b and T 

• Category 3 — card type 3 

• Category 4 — card type B 

• Category 5 — other card types 

• Category b - N card 

A generalized function for adding new 
records and updating existing records will 
exist. This function, which is driven by 


input formats, data base formats, and card 
type, will add or modify the specified 
record. The general steps of processing 
input cards are as follows. 

• Read input card 

• Generate record ID (See table 7-2) 

• Generate external (input) format ID from 
table 

• Retrieve record 

• Retrieve formats 

• Either add or update record (or both in 
case of "N" card) 

• Output card image reflecting success or 
error 

Figure 3-7 depicts the flow of this process 
and variations dependent upon category of 
card type. 

Table 7-1 indicates the data used for gen- 
erating a record depending on input category. 
The input format is a function of the card 
type . 

The type of operation, an add or modify, to 
be performed is a function of the category 
for the record type and whether or not a 
record already exists. The input format 
for the card type identifies the fields it 
updates and the field's data types. Table 
3-5 describes the processing for field 
types or input. The processing of individual 
fields is transparent to this routine (it 



Process Description: is performed by AUREC) . 

(continued) 

If an error condition occurs when processing 
an input card, an error type is put in 
column 2 when the image is written to the 
message file. The input card images for 
new DAPTS records are also written to the 
message file; column 2 for them is the 
logical unit number for the DAPTS record 
file . 

Additional processing required by category 3 
is the selection of FLOCON records of the 
same segment and the updating of their 
biowindow fields. 



TABLE 7-1.- PROCESSING DESCRI 





TABLE 7-2.-> CARD TYPE 


A 

2 

3 

4 

5 

6 
T 
B 

Others 


RECORD ID GENERATION TABLE. 


)thod o£ Generating Record ID 


S eminent number 
Seg\}ent number 
Segiv*;nt number 
Segment number 
Segment number 
Segment number 
Segment number 
Segment number 

Segment number and Acq. date 
Segment number and Acq. date 



Name: 


AUREC 


Purpose: 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


To either add or update a record to the 
data base. 

• Calling sequence: CALL AUREC (J, IFUN, STAT) 

• Common blocks used: SYSCOM, SY2C0M, 

UPDCOM 

• Subroutines or functions used: LMVTAB, 

APSTUP, TFORM, ADDR, REPR 

• Files used; Units 9 and 10 for auto 
posting . 

IFUN = 1 indicates ADD, IFUN = 2, indicates 
update 

SY2COM contains the record to be added or 
modified 

J ® record ID 

STAT = status return 

Data base is updated or modified 
Key changes are on Unit 9 and 10 
Status reflects results of operation 

- status = 0 

- status = 1 

The system move table is updated 

Fields are transformed from input array to 
output array according to move table 

Fields are posted if required 

Fields are unposted if required 


Process Description: 
(Continued) 


Records are theft added or modified using 
ADDR or RE PR 



Name : 


BLKLN (preprocessor step 3) 


Purpose : 

Linkage : 

Input Description: 
Output Description: 


Prints a blank line 

• Calling sequence: CALL BLKLN 

• Common blocks used: UNITS, LINES 

• Subroutines or functions used: None 

• Files used: UNIT = 7 

Unit number IU37 
Line counter LINE 

Writes one blank character to vmit 7, incre- 
ments the line counter LINE 


Process Description: Write unit 7 and increment LINE. 


Name : 

Purpose: 

Linkage : 

Input Description: 
Output Description: 

Process Description: 


BLNKCK (preprocessor, step 1) 

To check update cards for nonblank charac- 
ters and force blanks in columns that will 
be used for flags. 

• Calling sequence: CALL BLNKCK 

• Common blocks used: UNITS, IMAGES, BCHK 

• Subroutines or functions used: None 

• Files used: Logical unit 9 

Update card image in IMG array; a list of 
card columns in array ICOL 

The same card image, with listed columns 
forced to blanks. , 

A list of cards in which forcing was 
required on unit 9 

Each column in the list ICOL is checked for 
a blank. 

If any column is nonblank, the unchanged 
image is written to a list file, and all 
columns are then forced blank. 

A non-blank is not a fatal error of the 
update. 




Name; 


CARTP (preprocessor step 3) 


Purpose : 


Linkage; 


Input Description; 


Output Description; 


Process Description; 


To separate cards with types 2 , or 3 
from all other update cards. 

• Calling sequence; CALL CARTP 

• Common blocks used; FLAGS, UNITS, LINES, 
IMAGES 

• Subroutines or functions used; PAGE, 

HDR, BLKLN, COLABL 

• Files used: Units 1, 3, 5, 7 

Card images in array IMl 

Current phase's unit number for *, 2, 3 
cards in IU33P 

Unit number for other card types in IU35P 

A count of cards of one type in ICTCT. 

Card images to the listing file (unit 7) 
and to other units as follows: 


Unit Type Phase 

3 *,2,3 2 

4 *,2,3 3 

5 Other 2 

6 Other 3 


Appropriate unit numbers for the phase now 
being processed are selected by card type 
of the image in the IMl array. Calls to 
subroutines provide page and column headers 
and page number control. 



Name: 


CHAR 


Purpose: 


Linkage: 


Input Description: 


Output Description: 


To convert an integer to a string of ASCII 
digits . 

• Calling sequence: CALL CHAR ( string , 

start , length , l value ) 

where 

value is the integer to be converted, 

length is the number of digits to be 
produced, 

start is the leftmost character position 
in the output string, and 

string is the output string. 

• Common blocks used: None 

• Subroutines or functions used: None 

• Files used: None 

Value , length , and start should be typed 
INTEGER*4 

Value should contain a non-negative integer 
in the range 0 < value <2 - 1 

The array string should be long enough to 
hold start + length - 1 characters 

A field of length characters is filled with 
the ASCII codes for the decimal representa- 
tion of value . Leading zeros are not sup- 
pressed. Overflow of the field is not 
detected: the low-order digits will be 

given with no error indication. 


Processing Description: 


Standard di vide -by- modulus -and -use - 
remainder conversion algorithm. 


Name : 


CKTYLP (preprocessor step 1) 


Purpose: 

Linkage: 

Input Description: 
Output Description: 

Process Description: 


To check update cards for type and phase 

• Calling sequence: CALL CKTYLP 

• Common blocks used: IMAGES, VALID, 

FLAGS, UNITS 

• Subroutines or functions used: QCHCK 

• Files used: Logical units 4, 5, 7, 8 

Update card image in array IMG 

The updated card image list of invalid 
card type on unit 7 and invalid phase on 
unit 8. 

Card images of phase 2 and phase 3 are 
written on units 4 and 5, respectively. 

Each card is initially checked for Q-type 
in column 2 . 

If Q-type, the card is treated as a special 
case. 

If element 2 of the image has an invalid 
type or phase, the image is written to a 
list file (units 7 and 8, respectively). 

All valid phase 2 and phase 3 images are 
written to output files (units 4 and 5, 
respectively) . 


Name: 


CLOSEL 


Purpose : 

Linkage : 

Input Description: 

Output Description: 
Process Description: 


To insert a trailing comma if necessary. 

• Calling sequence: CALL CLOSEL (STR, S 

L) 

• Common blocks used: None 

• Subroutines or functions used: LAST 

• Files used: 

STR - string name 
S - start 
L - length 

STR with a trailing comma. 

Find the last non-blank character and 
insert a comma as command delimiter. 



Name : 


CMDRI 


Purpose: 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


To control the process of the arithmetic 
command CM. 

• Calling sequence: CALL CMDRI 

• Common blocks used: SYSCOM, SY2C0M 

• Subroutines or functions used: INDEX, 

INPARM, SUBSTR, CMPUTE 

• Files used: None 

User's command string through common block 
SYSCOM (STR) 

Mean, standard deviation, count of records 
used in computation and count of total 
number of records in a given set. (See 
output description of subroutine CMPUTE) . 

The following processing is performed. 

The command string is parsed. 

A format array is set up with the two 
field names. 

Working program (CMPUTE) is called. 



Name : 


CMPUTE 


Purpose : 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


To compute mean and standard deviation of 
the differences of two fields from a set 
of records , 

• Calling sequence: CALL CMPUTE (RID, SET) 

• Common blocks used: SYSCOM> SY2C0M 

• Subroutines or functions used; ADDR, 
CLOSER > GETREC, INPARM, LMVTAB, SETINl, 
VERIFY, XXINl, SSORT, LODREC 

• Files used: None 

RID is the record ID for the record where 
the results of the computation are to be 
stored. 

SET is the set number for which all compu- 
tations are to be performed. 

Mean and standard deviation of differences 
of two fields, count of number of records 
used in mean computation and the count of 
the total number of records are stored in 
the specified record. 

The following processing is performed. 

Get record ID from set 
Retrieve record and associated format 
Process retrieved record as follows: 
Differences of two fields is computed 
for records in which neither field 
is blank. 


Process Description: 
(continued) 


Count of number of records used in com- 
putation of mean and standard deviation 
is maintained. 

The mean and standard deviation are computed 
after all records have been processed. 

Encode all computed results to alphanumeric. 

Call ADDR to store encoded results in the 
specified record. 


Name: 


COLABL (preprocessor step 3) 


Purpose : 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


Provides a printed header giving field 
identification for the update card listing. 

• Calling sequence: CALL COLABL 

• Common blocks used: LINES, UNITS 

• Subroutines or functions used: BLKLN 

• Files used: Logical UNIT = 7 

LINE (current line number on the page now 
being printed) 

ICOLAB (a flag that indicates whether col- 
umn labels have already been printed on 
the current page. The flag is reset when 
HDR starts a new page) 

Column headers for the fields of update 
cards (card type, segment number, etc.) 

If the flag is reset (ICOLAB = 0) the 
headers are printed and the flag is set 
(ICOLAB = 1) 



Name : 


COMSTR 


Purpose: 

Linkage ; 

Input Description: 

Output Description: 
Process Description: 


To compare two strings (SEE KOMSTR) . 

• Calling sequence: I = COMSTR (A, SI, 

LI, B, S2, L2) 

• Common blocks used: None 

• Subroutine cr functions used: None 

• Files used: None 

A - first string 

51 - start in first 
LI - length in first 
A - second string 

52 - start in second 
L2 - length in second 

-1 - A<B 
0 - A=B 
+1 - A>B 

If LI y L2 the shorter string is considered 
to be blank filled. 



Name : 


COUNT (preprocessor step 3) 


Purpose : 

Linkage : 

Input Description: 
Output Description: 


Puts out a count of the current card type. 

• Calling sequence: CALL COUNT (IC) 

• Common blocks used: LINES, UNITS 

• Subroutines or functions used: None 

• Files used: Logical UNIT » 7 

The integer card count in parameter IC 

On the listing file 7, a 6-digit integer 
starting in print column 88 


Process Description: 


A FORTRAN write statement. 


1 


Name: 

Purpose : 

Linkage: 

Input Description: 
Output Description: 
Process Description: 


CREATE 

Initial data base load 

• Calling sequence: Main program 

• Common blocks used: None 

• Subroutines or functions used: GETLEN, 

GETSTR, GETKEY 

• Files used: None 

Depends on application. 

A RIMS-format data base 

For a large initial load this is the most 
efficient method. The three routines used 
are application dependent, and must be user 
supplied. 



9f 


Name ; 


DASHES (preprocessor step 3) 


Purpose : 

Linkage : 

Input Description: 
Output Description; 


Writes out a line of dashes to separate 
counts from totals. 

t Calling sequence: CALL DASHES 

• Common blocks used: LINES, UNITS 

• Subroutines or functions used; None 

• Files used: Unit 7 

Listing file unit number in IU37 
10 hyphens in print columns 84 through 93 


Process Description; A FORTRAN formatted write. 


Name : 


DSJFM 


Purpose: 


Linkage : 


Input Description; 


Output Description: 


Process Description; 


To control the process of the JF command 
(display data from two data base levels) 
and to load the display format. 

• Calling sequence: CALL DSJFM 

• Common blocks used: SYSCOM, SY2C0M 

• Subroutines or functions used; INDEX, 
INPARM, LODFMT, RECTRC 

• Files Used; None 

User's command string through common block 
SYSCOM (STR) 

A set of records containing data from two 
data base levels is displayed. 

The following processing is performed: 

The command string is parsed. 

The display format record is loaded by 
given format ID. 

Working program (RESTRC) is called. 



Name; 


ENDSET 


Purpose; 

Linkage: 


Input Description; 

Output Description; 
Process Description: 


To enter a set into the status table. 

• Calling sequence: CALL ENDSET (HIT, 

UNIT) 

• Common blocks used: SYSCOM 

ALT. ENTRY POINT: MODE 

• Subroutines or functions used; NHITS, XXOUl 
e Files used; 

HIT « # items in set 

UNIT ** logical unit containing set 

Updated status table. 

Test for non-empty set and use XXOUT to 
write set to file 5. 


/b«h 


Name; 


EQUALS (preprocessor step 3) 


Purpose: 


Linkage ; 


Input Description: 


Output Description; 


Writes out a line of equal signs to separate 
count from grand totals, 

• Calling sequence: CALL EQUALS 

• Common blocks used: LINES, UNITS 

• Subroutines or functions used; None 

• Files used: Logical UNIT » 7 

Print file unit number in IU37 
Current line number in LINE 

10 signs in print columns 84 through 93 


Process Description: 


A FORTRAN formatted write statement. 


Name : 


GETCLD 


Purpose : 
Linkage: 


Input Description: 
Output Description: 

Process Description: 


To form a set of children records; for a 
given set. 

• Calling sequence: CALL GETCLD (SET) 

• Common blocks used: SYSCOM 

• Subroutines of functions used: SETINl, 

SETOUT, XXINl, XXOUT, ENDSET, LOCREC, 

GET 

• Files used: Input set on Unit (5) or 

Unit (3) and output set is on Unit (5). 

Set contains the parent set number. 

The children set description jj placed in 
the next available set of the status table. 
Resulting set is on Unit 5. 

1. Initialize input/output files, counters 

2. Get next record ID from input, end 

3. Error check 

4. Position data base unit 2 to parent 

5. Follow logical sequential read in unit 
2, writing children record ID's in 
target set until left half of word does 
not match parent record ID. 

7. Close output file, update status table, 
TABNO, etc. 


l-^< 



Name : 


GHTLEN 


Purpose : 

Linkage : 

Input Description: 
Output Description: 
Process Description: 


To return, via KliYLHN, the length 
keys in words. 

• Calling sequence: CALL GETLliN 

• Common blocks used: Unknown 

• Subroutines or functions used: 

• Files used: Unknown 

(As desired by the user of CREATE") 
KEYLEN 

(To be siq)])lied by the user") 


7 ->3 5 


f the 

KEYLEN) 

Unknown 


N 


Name : 
Purpose : 

Linkage : 


Input Description: 
Output Description: 

Process Description: 


GETPAR 

To form a set of parent records for a 
given set. 

• Calling sequence: CALL GETPAR(SET) 

• Common blocks used: SYSCOM 

• Subroutines or functions used: SETINl, 

SETOUT, XXINl, XXOUT, ENDSET 

• Files used: Input on 3 or 5, output on 

5. 

SET contains children set number. 

The parent set description in the next 
available set in the status table — the 
set is on unit 5. 


1. Initialize I/O files, counters 

2. Get next record ID from input, end 

3. Error check 

4. Form parent record ID by setting right 
half of ID to zero, write result on 
output unit, ignore duplicates 

5. Go to 2 

6. Close output file, update status table, 
TABNO, etc. 


/Uls> 


Name : 


GliTQ (preprocessor step 3) 


Purpose : 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


To use Q card files (only) in setting 
trr-.rsi: tion dates. 

• Calling sequence: CALL GETQ (IPXl 

• Common blocks used: UNITS, FLAGS, IMAGES, 

LINES 

• Subroutines or functions used: ABORT, 

HDR, BLKLN, COLABL , DASHES, COUNT, PAGE 

• Files used: Units 1 , 2 , 3 ,4 , 5 ,6 , 7 , 8 

The input parameter IPX is the LACIE Phase 
(2 or 3 in integer form) 

Array lUN contains logical unit numbers for 
input and output files. 

Subroutine IMIGET is called to get card 
images through array IMl. 

Page headers and the Q card image are 
written to the report file. The default 
transaction date from the Q card is saved 
in array IMQ. 

This routine follows two separate paths 
for the two LACIE phases. Different input 
files and output files are set up for the 
two phases. The first Q card from the 
Phase II file is saved to provide the trans- 
action date for those cards in which it has 
not been punched. Duplicate Q cards are 
detected: an exact duplicate is allowed, 

but 2 different Q cards will cause step 3 
to abort. 


/iy / 


Name : 


GETSTR 


Purpose : 

Linkage : 

Input Description: 
Output Description: 
Process Description: 


To provide a record to CREATE 

• Calling sequence: CALL GETSTR (ACC ,REC) 

• Common blocks used: Unknown 

• Subroutines or functions used: Unknown 

• Files used: Unknown 


ACC,REC 

Upon return, ACC should contain the record 
number in ascending sequence, and REC 
should contain the record. The first 
word of REC should contain the record 
length, not counting itself. ACC = 0 
signals end of file. 




I 


Name ; 


HDINIT (postprocessor) 


Purpose : 

Linkage: 

Input Description: 
Output Description; 

Process Description: 


/ 


Puts headers on output files 

• Calling sequence: CALL HDINIT 

• Common blocks used: UNITS 

• Subroutines or functions used: 

• Files used: Units 1, 2, 3, 4, 5, 6, 

Logical unit numbers in array lUN 

Appropriate header lines are written out 
to the output files 

FORTRAN formatted write statements 


/^f 


Name : 


HDR (preprocessor step 3) 


Purpose : 

Linkage : 

Input Description: 
Output Description: 

Process Description: 


Print the header label information at the 
top of a page. 

• Calling sequence: CALL hDR 

• Common blocks used: LINES, UNITS, IMAGES 

• Subroutines or functions used: BLKLN 

• Files used: Logical UNIT = 7 

Header date in IMQ array (Q card image) 

LINE counter set to 12 

Column label flag reset (ICOLAB = 0) 

Header printed on listing file (Unit 7) 

Write the header and two blank lines, then 
set the line counter and column label flag. 




Name : 


HEADER 


Purpose : 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


To print a line o£ text report. Provides 
for comments and headers . 

• Calling sequence: CALL HEADER 

• Common blocks used: SYSCOM, SY2C0M 

• Subroutines of functions used: INDEX, 

INPARM, SUBSTR 

• Files used: Report file (12), message 

file (7) and command file (13) . 

User's command string through common block 
SYSCOM (STR). 

One line of the header contents or com- 
ments is printed. 

The following processing is performed: 

The command string is parsed. 

Print header or comment up to 66 char- 
acters long as input if N = 1. 

Read record line of header or comment up 
to 62 characters long from command file 
and print it's contents immediately after 
where first line ended if N * 2. 

N should be either 1 or 2 syntax error is 
printed otherwise. 


Name : 


IMIGET (preprocessor step 3) 


Purpose : 


To check card, images for duplicates and 
write them out. 


Linkage : 


• Calling sequence: flag » IMIGET ( unit ) 

• Common blocks used: FLAGS, IMAGES, UNITS 

• Subroutines or functions used: None 

• Files used: UNIT lUNX, 1U38 


Input Description: Input update card file unit number in param- 

and either (a) a card image already 
read into array IM2 or (b) flag IM2MT»1 when 
IM2 is empty because an end-of-file was read 
from the unit file. Unit number of error 
file for duplicates, IU38. 


Output Description: 


The flag value 
from this function 


0 where a new card 
image is in IMl 

1 when no image is 
available 


If available, one more image has been read 
into IM2 and checked for duplication of IMl. 
Duplicates are written to error file IU38. 
The next card image to be used is in IMl. 


Process Description: Move card image 2 into card image 1 (if there 

is a card image in card image 2) . Read 
another image (if any) into card image 2, 
checks the two images (card image 1 and 
card image 2) for duplicates. Duplicates 
are written to the error file and reading 
continues until a different card is 


/O- 


Process Description: 
(concluded) 


encountered or the end of the input file 
is reached. At end-of-file, the flag IM2MT 
is set » 1 to indicate that array IM2 is 
empty. 



Name: 


INIT (preprocessor step 1) 


Purpose : 

Linkage: 

Input Description: 
Output Description: 

Process Description: 


Initializes step 1 output files. 

• Calling sequence: CALL INIT 

• Common blocks used: UNITS 

• Subroutines or functions used: None 

• Files used: Logical units 7, 8, and 9 

Array of logical unit numbers, lUN. 

Header lines for the listing files for 
invalid cards. 

1. Set unit numbers to values from lUN 

2. Write header records to those files 



Name: 


IRECK (preprocessor step 5) 


Purpose; 

Linkage : 

Input Description: 
Output Description; 

Process Description: 


To read Input card images. 

• Calling sequence; flag * IREGK( index ) 

• Common blocks used: CARDS, UNITS 

• Subroutines or functions used: None 

• Files used: Unit lUN(l), the input file 

Input parameter index specifies which of 
the four card buffers in array IM should 
receive the card image from the input file. 

The flag value of this function is *0 if an 
image was read, *1 after an end-of-file. 

The card image is left in the specified 
slot of array IM. 

Read the input file and set the flag. 



Name: 


lUNLD 


Purpose; 


Linkage ; 


Input Description; 


Output Description; 


Process Description: 


To test for unload (UNLD) cards and reformat 
them into an *'N" card. 

e Calling sequence: CALL lUNLD (image) 

# Common blocks used: None 

e Subroutines or functions used: None 

# Files used: None 

The input array image is an 80-character 
ASCII code card image. 

The array i mage is reformatted in place 
to the usual ASATS format. 

If the image does not match the string 
’UNLD', return. If it does match, leave 
the ’N’ in column 2, move the segment 
number from columns 10-13 to columns 4-7, 
move the acquisition date from 17-20 to 
9-12 and insert a "3" in column 8. The 
tape number from columns 45-50 will be 
moved to columns 19-24. The transaction 
date field columns 14-17 will be left 
blank for insertion of the default date 
from the Q card, and the remaining unused 
columns will also be set blank. 


Name: 


Update Processor Main Program 


Purpose: 


Linkage: 


Process 


To control execution of bulk update from 
ASMS cards. 

• Execution: RUN ASMS 

• Common blocks used: SYSCOM, PDT 

• Subroutines or functions used: BE, REAP, 

CLOSER, END, AUDATE, ASN, RED 

• Files used: U(14) is used for reading 

commands , 

Description: Reload and interprets commands. Causes 

appropriate subroutines to be executed to 
process given commands. Acceptable commands 
are: BE, RF, RE, UP, EN. 



Name : 


KSGEQ (preprocessor step 5) 


Purpose : 


Linkage : 


Input Description; 


Output Description: 


Process Description; 


To compare the segment number o£ the card 
just read to the first card in the buffer 

• Calling sequence: flag = KSGEQ (index ) 

• Common blvcks used: CARDS 

• Subroutines or functions used: None 

• Files used: None 

The input index specifies which card slot 
in array IM is to be compared to the card 
in the first slot. The two card images are 
both in array IM. 

The value of the output flag is *1 if the 
segment numbers are equal and =0 if they 
are different. 

Loop through the 4 segment number digits 
and set the flag to zero if they are 
different. 


//S' 


Name: 


LAST 


Purpose ; 


To find the last non -blank character in a 
string. 


Linkage : 


• Calling sequence: I «* LAST (STRING, 

START, LENGTH) 

• Common blocks used: None 

• Subroutines or functions used: None 

• Files used: None 


Input Description: 


STRING ® string name 
START ® starting position 
LENGTH = length of substring 


Output Description: 


Location of last non-blank. 


Process Description: 


Establishes index pointer to last non-!)lank 
character in the string. 


Name : 


MAIN ( I'oti 1 1 > root's so r ) 


Purpose : 


Linkage : 


Iu[)ut Peso r ipt urn : 


Output De.scr ipt i on : 


Process Descript ion: 


(lives a listing of new segrient recorvls, 
invalid new acquisitions, cards to be 
punclu'tl, a file Tor images of cards punched, 
updates (’or records, and packet laheU 
for a RIMS update input file, 

• Calling sequence: Not applicalMe 

• Common blocks usoil: UNITS, ARRAYS 

• Subroutines tir funct ions used: UNINIT, 

IIDINIT 

• Tilt'S used: Units 1', i' , 8, 1 ti 

liqnit file from RIMS uptlato process. bach 
input record contains a carriage cojitrol in 
the first character :iiui an AS('. I 1 tligit desig 
nating the output file in the secoiul 
character . 


The recoi'tls from the iiqnit file arc copii'd 
tc> the output lileis) designatcvl bv the 
secoiul character of each record. ffhe 
second character itself is not written outl, 

A heailer rt'corti is written to ident i f\‘ t-av h 
of the output files. After cejn'ing all the 
input records to the n[qiroi'riate output 
,les, the choice of program STtM’ statements 
will give a message on the operator's console 
to let him know whether the punch and label 
files are emptv for today's run. 


Name : 


Main progi'am, prcpi’ocessor step 1 


Purpose : 
Linkage ; 


Input Description: 
Output Description: 

Process Description: 


To control listing of update cards and 
the checking for invalid cards. 

• Calling sequence: Not applicable 

• Common blocks used: IMACbS, lU'.llK, 

110Li:0N, lINlTvS, VALID, PLACS 

• Subroutines or functions used: MUiR 1' . 

BLNKCK, CKTYLP, liXIT, IN IT, UN IN IT 

• Piles used: l.ogical units 1, 3, vuui I 

ASATS update card images from logical unit 1 

IJnsorted listing of input on unit 3, counts 
of valid and invalid cards on unit 10, error 
abort message on unit 10 

This ]n'ogr;>m reads the update cards and 
lists them. It calls subroutines to cliecL 
them for validity and write the valitl 
cards to files for later processing. 


Name : 


Main program t preprocessor step 3) 


Purpose : 
Linkage : 


Input Description: 
Output Description: 

Process Description: 


Gives a report of the update card images. 
The report includes counts of each card 
and total counts for eacVi phase. 


• Calling sequence: Not applicable 

• Common blocks used: UNITS, LINP.S, 

IMAGliS, b'LACS, LliCTY 

• Subroutines or runctlons used: UNINIT, 

CLTQ, PllASli, IIDR, COLAHL, PQUALS, COUNTS. 
PACh, I'XIT, NONQ, ABORT, IMlCliT, PAG!: 

• Files used: Logical UN 1 IS - 1 , J , 3 , -I , S , e , " , 8 

ASATS update card images 

Audit files for update cards and the update 
card files themselves. 

This program controls the sequence of calls 
to produce a combined report of update cards 
for Phase 2 and Phase .3, separated wltlrin 
the phases hy card type. Page headers and 
page numbers and a grand total count of 
cards are given. 



Name : 


MAIN (preprocessor stop S) 


Purpose : 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


To control the scimration of comiiJeto seg 
ment descriptions (*, 2, and 3 cards for a 
segment), which may be either now segments 
or updates for existing segments, from 
single update cards. 

• Calling sequence: Not applicable 

• Common blocks used: CARDS, UNITS 

• Subroutines or functions used: UNINIT, 

WRNIJK, MVMRl , IRliCK, KSOnQ 

• Piles used: Units 1, 3, 5, 7 

The input file (unit 1) contains all tlic 
*, 2, 3 cards in today's update deck sorted 
into order by segment so that all cards 
for one segment will be found in sequence. 

Output files units 3 and 5 contain, respect- 
ively, the complete sets, with the card 
changed to a "Z" type, and the incomplete 
sets . 

Cards are read (by subroutine TRRCK) into 
the 4 -card buffer IM until either a change 
of segment number occurs, or the buffer is 
full, or the end-of-file is reached. A 
check is then made to see whether 3 cards 
for one segment of the three types *, 2, 
and 3 have been read. If so, tliey are 
saved as a set. Otherwise, they are saved 
as a nonset, and the process repeats. 


Name : 


MOVSI'C 


Purpose : 

Linkage : 

Input Description: 
Output Description: 
Process Description: 


To parse the command for MO and to move 
information from the status table into a 
record . 

• Calling sequence: CALL MOVSHG 

• Common blocks used: SYSCOM 

• Subroutines or functions used: GliTRHC, 

CHAR, REPR 

• Files used: U(7) 

STR, the text of the command line 

Updated record in base. 

The set count from TAB is converted to 
character form and placed in tlic projicr 
record . 



Name : 


MVMRl (preprocessor step 5) 


Purpose : 

Linkage : 

Input Description: 

Output Description: 
Process Description: 


To move a line in an array to the beginning 
of the same array. 

® Calling sequence: CALL MVMRl (i ndex ) 

• Common blocks used: (’ARDS 

• Subroutines or functions used: None 

• Files used: None 


Input parameter index specifies which card 
image slot in array IM should have its data 
moved up to the first slot. 

The card image in the first slot of IM. 

Loop through the image and move one charac- 
ter at a time. 




Name : 


NONQ (preprocessor step 3) 


Purpose : 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


Puts the default value of transaction date 
from the Q card into those card images 
which need them. 

• Calling sequence: flag » NONQ ( unit ) 

• Common blocks used: FLAGS, IMAGES, 

LEGTY, UNITS 

• Subroutines or functions used: IMIGFT 

• Files used: Update card input file ( unit ) 

An update card image in array IMl is supplied 
by the call to IMIGFT. Array IMQ contains 
the transaction date from the Q card. 

ASATS card image in IMl, with the transac- 
tion date inserted in those cards which 
need it. The flag value from NONQ is 0 
when a new card is in IMl, 1 otherwise. 

Get a card image (and quit at end of file). 

If the card type field matches one of the 
list of card types in array IVTYP, tlie 
transaction date field is checked. If that 
field is blank, the default date from the 
Q card image is inserted into it. 



Name : 


PACr, (processor step 3") 


Purpose : 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


Writes out a page number at tlic bottom of 
a page. 

• Calling sequence: CALI, P/ uP. 

• Common blocks used: LINDS, UNITS 

• Subroutines or functions used: BLKLN 

• Files used: UNIT » 7 

Logical unit number of tlic listing file in 
IU37 

Current page count IPACK 
Current line number LINli 

Incremented page numlier in IPACdi. 

On the listing file: enough blank lines to 

reach the bottom of the current page, and 
the page number 

The page number is negated to get a leading 
hyphen, and a trailing hyphen is supplied 
by the format . 




Name: 


PARSP.C 


Purpose : 

To 

parse the command string for C 

Linkage : 

• 

Calling sequence: CALL PARSRC 


• 

Common blocks used: SYSCOM 


• 

Subroutines or functions used: 


• 

Files used: 


Input Description: Command lino in STR 

Output Description: vSot numhor in parameter K to Cl'TCl. 

Process Description: Call TNPARM to convert sot nunhor 

binary, and call Cl-TCI.D. 





GBTCLD 


Name : 


PARS HP 


Purpose : 

To 

purse the command string for UP. 

Linkage : 

• 

Calling sequence: CALL PARSLP 


• 

Common blocks used: SYSCOM 


• 

Subroutines or functions used: 


• 

Files used: 


Input Description: Comniaml line in STR arrnv 

Output Description: Set mimhor in parameter K to (li'rrA": 

Process Description: Use INPARM to convert number, check it is 

legal set number, and call GIITPAR 




Name ; 


PHASH (preprocessor step 3) 


Purpose: 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


Output all cards of all types found in one 
phase, 

• Calling sequence: CAi.L PHASE (IP) 

• Common blocks used; UNITS, LINES, FLAGS 

• Subroutines or functions used: IlDR, 

BLKLN, CARTP, PACE, COLADL, DAvSUES , 

COUNT 

• Files used; Logical UNIT = 7 

Input parameter IP in the LACIE phase 
(Integer 2 or 3} 

Count of cards for the phase in IPCT. 

Audit report on unit 7. 

This routine (by calling subroutines) for- 
mats a complete audit listing of all cards 
for one phase. It starts with a page 
header for the phase, steps through all 
card types in the file for that phase, and 
produces a total card count for that phase. 



Naipe: 


PSWRD 


Purpose: 

Linkage : 

Input Description: 
Output Description: 

Process Description: 


To read the password, scramble it and 
overstrike it on the scope. 

• Calling sequence: CALL PSWRD (I) 

• Common blocks used: SYSCOM 

• Subroutines or functions used: None 

• Files used: 11(7'), 11(131 

Password 

Scrambled password (in I) 

NOTE: The scrambled password will be used 

as a record i.d. for a record containing 
the bit mask. 


/B* 


Name : 


QCHCK (preprocessor step 1) 


Purpose: 

Linkage : 

Input Description: 
Output Description: 

Process Description: 


Check for duplicate or illegal Q card 

• Calling sequence: CALL QCHCK 

• Common blocks used: FLAGS, IMAGFS, UNITS 

• Subroutines or functions used: None 

• Files used: Units 4, 5, 7 

Update card image in IMG array 

A list of Q card images to an output file 
(units 4 and 5, respectively). 

A list of duplicate or different Q card 
images to unit 7 (if more than one Q card 
has inadvertently entered) . 

If counter IQCT=0, the first Q card is 
written to units 4 and 5, respectively. 

Then a check for duplicate or different 
Q cards is made. 

If a duplicate is found, the counter I()GT 
is left=l. 

If a different Q card is found, counter 
IQCT is incremented by I and an error flag 
is set. 




Name : 


RF.D 


Purpose : 


Linkage : 


Process 


To read processing description for update 
card types and build processing description 
table . 

• Calling seciuence: CALI. Rlil) 

• Common blocks used; /PDT/CTAB, I’NO, 

RIDT, PTT 

• Piles used; Card images are read from 
unit 12. 

Description: Card images are read until a blank card 

type is encountered. Table 7-3 illustrates 
format of cards. The results of the card 
images arc stored in CTAR (card type table), 
FNU (format number), RIDT (record ID typo), 
and PTT (processing type table). 


TABLE 7-3.- PROCESS DESCRIPTION 
CARD IMAGE FORMAT 


Field 

Columns 

Card Type 

1 

Input Format 

2-4 

Record ID 

5 

Generation Type 


Processing Category 

6 





Name : 


RESTRC 


Purpose : 


Linkage : 


Input Description; 


Output Description: 


Process Description: 


To display a set of records containing 
information from both the records within 
a specified set and their parent records. 

• Calling sequence: CALL RliSTRC (SLT) 

• Common blocks used: SYSCOM, SY2C0M 

• Subroutines or functions used: DISFMT, 

INPARM, LMVTAB, LODFMT , LODREC , SETINl , 
SUBSTR, TFORM, XXINl 

• Files used: None 

SET is tlie set numl)er for a set of records 
with same format ID (i.e. a set of FLOCON 
records) 

SY2C0M contains the display format. 

Records within a given set and their parent 
records are displayed as specified. 

The following processing is performed. 

(1) Get record ID from set. 

(2) Retrieve record and associated format. 

(3) Transfer data from retrieved record 
(FLOCON) to an output buffer according 
to the display format. 

(4) Generate record ID for associated record 
with different format (DAPTS) . 

(5) Retrieve record with generated record 
ID and its's associated format. 



Process Descript 
(Continued) 


ion: (6)Transfor data from retrieved record 

(DAPTS) to output buffer according to the 
display format 

(7)Display program (DISFMT) is called, (to 
write output buffer to report file! , 



Name : 


SMINUS 


Purpose : 

Linkage : 

Input Description; 
Output Description; 
Process Description; 


To delete a password from the base, 

• Calling sequence; CALL SMINUS 

• Common blocks used: SYSCOM 

• Subroutines of functions used; DECK,PSWRD 

• Files used: u(7) 

PASSWORD 

Record removed from base. 

Hash the password, find it, and remove 
that record. 



Name : 


SPLUS 


Purpose: 

Linkage : 

Input Description: 
Output Description; 
Process Description: 


To add a password to the base. 

• Calling sequence: CALL SPLUS (SECURFl 

• Common blocks used: SYSCOM 

• Subroutines or functions used; PSWRP,ADDR 

• Files used; U(7), U(13) 

PASSWORD, BIT MASK 
New record in base. 

Hash the password and generate a new 
password record. 




Name : 


STCNT 


Purpose : 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


To print a line o£ text followed by the 
number of entries in a given set. Pro- 
vides for printing number of entries in a 
set with a label . 

• Calling sequence: CALL STCNT 

• Common blocks used: SYSCOM, SY2C0M 

• Subroutines of functions used: INDLX, 

INPARM, SUBSTR 

• Files used: Report file (12), message 

file (7). 

User's command string including set number, 
column count and text comment through 
common block SYSCOM (STR) . 

Text comment with number of entries is 
printed. 

The following processing is performed: 

The command string is parsed. 

A format is formed according to the given 
column count. 

The text comment and number of entries 
are printed using the formed format. 

The length of text comment is limited to 
(column count -4) characters long. Dis- 
regard any character exceeding the limit. 


1 ^ 

/sr 


Name: 


T’^ORM (normal version) 


Purpose: 


Linkage: 


Input Description: 


Output Description: 


To transform data from one format to 

another format. 

• Calling sequence: CALL TFORM(I) 

• Common blocks used: SYSCOM,lJPDCOM 

• Subroutines or functions used: SUBSTR, 

VERIFY, INPARM, CHAR 

• Files used: 

• UPDCOM/BIOTAB, FLAG type of card being 
processed 

• I is the source record 

• /SY2C0M/Buff contains input record 

• /SY2C0M/Buff contains output record 

• /SY2C0M/FMTID contains format ID's 

• /SY2COM/length contains record lengths 

• /SY2C0M/M0VTAB contains pointers to 
fields of each record 

• /SY2C0M/NM0V is the number of fields to 
be transformed 

• /SY2C0M/FMT contains formats for both 
records 

• SY2C0M/buff contains the resulting recor 

• /UPDCOM/FLAG contains reject indicator 



Process Description: The resulting record in the target buffer 

is constructed by moving data into a 
specified field. Data is moved according 
to the output type as follows: 

• Output type 0 is a straight move of 
characters from the source buffer to 
the target buffer. 

• Output type 9 moves data from the CC- 
ANCIL-TOPO table to the target buffer 
based on the source bufter value. 

• Output type 5 moves data from the Film 
Products table to the source buffer value, 

• Output type 4 moves data from the t!omputer 
Products table to the target buffer base 
on the source buffer value and the status 
(whether it is blank or not) of the 

"N" field. 

Figure 7-1 depicts the program flow. 

Table 7-3 reflects the use of the film 
status table. Table 7-4 reflects the com- 
puter products status table. Table 75 
reflects the CC-ANCTl,-TOPO table. 


















I 


TABLE 7-4.- FILM PRODUCTS STATUS TABLE (CURSl, output type 5 
translation) 


VALUE 


MESSAGE 


B 

G 

H 

I 

7 

8 
9 


PFC WORK 
LPDL REC’D 
PKT AVAL 
AI WORK 
GANG 
REOR 
REJT 






TABLB 7-5.- COMPUTER PRODUCTS STATUS TABLE 

(CURS2, output type 4 translation") 


VALUE 

UNLOAD 

CONTENTS 

MESSAGE 

B 

NA 

C § I WORK 

N 

NA 

I -100 RDY 

J 

NO 

BATCH STD 

J 

YES 

BATCH I- 100 

K 

NO 

ANAL STD 

K 

YES 

ANAL I -100 

M 

NO 

RERUN STD 

M 

YES 

RERUN I -100 

T 

NA 

I- 100 ANAL 

X 

NA 

Complet e 

7 

NA 

"LSD" Contents 

8 

NA 

"LSD" Contents 

9 

NA 

"LwSD" Contents 





TABLE 7-6.- CC-ANCIL-TOPO STATUS 


VALUE 

0 

1 

2 

3 

4 

5 

6 
7 


STATUS 

WORD 

Await C/A/T 
Await C/A 
Await A/T 
Await A 
Await C./'\' 
Await C 
Await T 
Complete 




Name : 


TFORM (update version) 


Purpose: 


Linkage s 


Input Description: 


Output Descriptioi 


To transform data from one format to 

another format. 

• Calling sequence ; CALL TFORM(I) 

• Common blocks used; SYSCOM,UPPCOM 

• Subroutines of Functions used: SUHSTR, 

VERIFY, INPARM, CHAR 

• Files used: 

• UPDCOM/niOTAB, FLAG type of card being 
processed 

• I is the source record 

• /SY2C0M/Buff contains input record 

• /SY2COM/Buff contains output record 

• /SY2C0M/FMTID contains format ID's 

• /SY2C0M/length contains record lengths 

• /SY2COM/MOVTAR contains pointers to 
fields of eacli record 

• /SY2COM/NMOV is the number of fields to 
be transformed 

• /SY2C0M/FMT contains formats for both 
records 

• SY2C0M/BUFF contains the resulting record 

• /UPDCOM/FLAG contains reject indicator 




Process Description: Fields are moved from the input record to 

the corresponding output record according 
to the input and output format specifica- 
tions. Figure 7-2 reflects the detailed 
flow. 
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Figure 7-2.— Continued. 
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Figure 7-2.— Concluded. 


Name : 


UNINIT 


Purpose : 


Linkage : 


Input Description: 


Output Description. 


Process Description: 


Assigns logical unit numbers tn file names 
at run time. 

• Calling sequence: Call UNINIT 

• Common blocks used: UNITS 

• Subroutines or functions used: System 

subroutine ASSIGN 

• Files used: STFP.'^ . lUN as unit 20 

Reads 2 -digit unit numbers from tlie 
first record with format 1912. Rest of 
records to end-of-filc are of the form 
212, 15A2 and each contains a unit number, 
the mnnber of characters in the file name, 
and the file name itself. 

Unit numbers arc saved in array IIJN* Unit- 
numbers to -f ilc - name associations are given 
to the system I/O control. 

Read the unit numbers and the file names 
and call the system routine ASSIGN. 

NOTH: Sliglitly different versions of this 

routine are used by steps 1, Z, and 5 of 
the Preprocessor, by the Postprocessor, 
and by tusks J.I and CONTAP. The differences 
are just the name of the file containing 
the file names and the common block used 
to store unit numbers. 



Name : 


UNLOCK 


Purpose ; 

Linkage : 

Input Description: 
Output Description: 
Process Description; 


To unlock the b;tse. 

• Calling sequence: CALL UNLOCK (SliCURP.) 

• Common blocks used: SYSCOM 

• Subroutines or functions used; PSWRD, 
LODRl-C 

• Piles used: 

Password 

Bit mask in SPCURF, 

The bit mask is used to lock (0) or unlock 
(1) tlie command. See JLASYS of the RTi'LS 
Maintenance Document for tlie command list. 
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Name : 


WRNUK (preprocessor step 5) 


Purpose : 


Linkage : 


Input Description: 


Output Description: 


Process Description: 


To write lines o£ an array to an output 
unit . 

• Calling sequence: CALL WRNUK ( number , 

unit ) 

• Common blocks used: CARDS, UNITS 

• Subroutines or functions used: None 

• Files used: Output file unit selected 

by calling program. 

number card images in array IM, and the 
unit number for the output file. 

The card images for a set or for a partial 
set are written to the appropriate file. 

A FORTRAN formatted write statement is exe- 
cuted the specified number of times. 



